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The  purpose  of  computing  is  insight,  not  numbers. 

-Richard  Hamming 

Abstract 

Wireless  sensor  networks,  or  WSNs,  are  an  emerging  commercial  technology  that 
may  have  practical  applications  on  the  modern  battlefield.  A  wireless  sensor  network 
consists  of  individual  sensor  nodes  that  work  cooperatively  to  collect  and  communi¬ 
cate  environmental  data.  In  a  surveillance  role,  a  WSN  could  be  deployed  across  a 
geographic  area  of  interest,  allowing  military  commanders  to  monitor  enemy  troop 
positions  and  movements.  Wireless  sensor  networks  have  enormous  potential  as  an 
information  gathering  tool,  but  they  also  present  many  unique  challenges  to  security 
engineers.  An  adversary  can  easily  capture  and  tamper  with  one  of  the  many  un¬ 
guarded  sensor  nodes  to  disrupt  or  significantly  degrade  the  quality  of  surveillance 
that  the  WSN  provides.  This  project  examined  potential  attacks  against  WSNs  and 
developed  a  modified  routing  protocol  that  increases  the  overall  data  integrity  and 
reliability  of  wireless  sensor  networks. 

Due  to  battery  limitations  of  individual  sensor  nodes,  many  WSN  protocols  seek  to 
conserve  power  by  simplifying  computations  and  reducing  the  number  of  radio  trans¬ 
missions  required  for  communication.  These  practices  allow  the  WSN  to  have  a  longer 
life  expectancy;  however,  such  protocols  are  easy  targets  for  enemy  exploitation.  In 
what  is  known  as  a  sinkhole  attack,  a  comprised  sensor  node  is  maliciously  used  to 
alter  the  wireless  mesh  of  a  sensor  network  for  the  purpose  of  disrupting  the  logical 
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flow  of  information  across  the  network.  The  purpose  of  this  project  is  to  minimize  the 
disruption  from  such  an  attack.  We  have  proposed  modifications  to  an  existing  tree 
based  routing  protocol  so  that  it  attempts  to  avoid  sinkholes  and  increase  the  over¬ 
all  data  throughput  of  the  network  by  sacrificing  some  of  the  networks  transmission 
efficiency.  The  efficacy  of  the  project’s  proposed  sinkhole  avoidance  strategy  is  also 
supported  through  the  use  of  software  based  WSN  network  simulations. 
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1  Motivation  For  Research 

In  business,  a  misinformed  decision  may  lead  to  falling  stock  prices.  In  war,  a  misinformed 
decision  may  lead  to  death.  A  warrior  does  not  deal  in  dollars,  euros,  or  yen.  He  or  she  deals 
in  the  currency  of  human  life.  Command  decisions  are  made  based  on  known  information. 
Accurate  and  timely  information  can  lead  a  commander  to  make  the  correct  decision  under 
the  severest  of  time  constraints.  In  a  modern  war  zone,  seconds  can  dictate  the  difference 
between  success  and  failure.  An  emerging  technology  -  wireless  sensor  networks  -  may  some 
day  provide  reliable  battlefield  information  to  commanders  in  real  time,  reducing  risk  and 
saving  lives. 


2  Introduction 

A  wireless  sensor  network,  or  WSN,  refers  to  a  group  of  small  battery  powered  sensors.  An 
individual  sensor,  commonly  referred  to  as  a  node,  consists  of  five  major  parts:  a  processor, 
digital  memory,  a  radio,  a  sensor  suite,  and  a  battery.  Additionally,  a  sensor  node  can 
be  fitted  with  actuators  that  allow  it  to  generate  power,  move  about  its  environment,  or 
perform  some  specific  task.  At  its  most  basic  level,  a  single  WSN  node  is  designed  to  be  a 
sensor.  Typical  sensor  suites  are  capable  of  detecting  changes  in  light,  sound,  temperature, 
pressure,  or  acceleration.  More  sophisticated  sensors  can  be  used  to  detect  seismic  activity, 
chemicals,  or  even  radiation  [1],  Wireless  sensor  networks  can  be  used  in  a  variety  of  peaceful 
applications,  for  example:  equipment  monitoring  in  industrial  facilities,  pollution  monitoring 
outside  of  power  plants,  or  allergen  monitoring  inside  of  hospitals.  Wireless  sensor  networks 
also  have  the  potential  for  many  military  applications.  Hundreds  or  even  thousands  of 
wireless  sensors  could  be  dropped  from  aircraft  and  spread  over  a  wide  geographic  area. 
These  sensors  would  be  able  to  set  up  a  surveillance  network  used  to  monitor  enemy  troop 
and  equipment  movement.  In  addition,  a  wireless  sensor  network  could  be  strategically 
deployed  by  special  forces  near  points  of  interest.  Considering  the  small  size  of  sensor 
network  nodes,  a  covertly  deployed  WSN  would  be  an  excellent  way  to  secretly  monitor  a 
hostile  force  or  installation  without  need  for  maintenance  or  personnel.  Such  covert  networks 
could  be  tied  into  a  satellite  data  link,  providing  constant  and  instantaneous  information  to 
command  centers  anywhere  on  the  globe  [2], 
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3  Background 

Wireless  sensor  networks  have  gained  a  wide  range  of  attention  in  the  past  decade  due  to 
their  promise  to  provide  reliable,  low  maintenance,  and  relatively  low  cost  sensors  that  can  be 
quickly  deployed  into  a  wide  variety  of  applications.  Wireless  sensor  networks  can  generally 
be  broken  up  into  two  categories:  structured  and  ad-hoc.  Structured  WSNs  consist  of  WSN 
networks  with  a  planned  deployment  of  each  sensor  node  with  regard  to  its  location.  Such 
deployments  might  be  seen  in  industrial  applications  where  Wireless  Sensor  Networks  are 
replacing  traditional  wired  sensors  (such  as  safety  valve  monitoring  at  an  oil  refinery).  Ad- 
hoc  WSNs  do  not  have  planned  deployments.  The  sensor  nodes  are  distributed  across  an 
area  of  interest  and  are  allowed  to  set  up  their  own  routing  structure  with  respect  to  the  base 
station(s).  Ad-hoc  WSNs  typically  consist  of  many  more  nodes  than  a  structured  WSN,  as 
a  higher  density  of  nodes  is  required  to  ensure  that  fault  tolerant  wireless  communication  is 
possible  between  all  nodes  in  the  network  and  the  base  station.  This  project  will  focus  on 
ad-hoc  wireless  sensor  networks,  as  ad-hoc  WSNs  are  more  suited  to  military  applications. 
An  ad-hoc  wireless  sensor  network  is  more  conducive  to  surveillance  over  harsh  terrain  in 
remote  geographic  locations.  An  ad-hoc  WSN  gives  the  user  the  ability  to  deploy  the  network 
quickly;  such  networks  could  be  quickly  deployed  by  fast  moving  ground  forces  or  military 
aircraft  [1]. 

There  are  a  number  of  different  protocols  and  hardware  sets  that  can  be  utilized  for  Wireless 
Sensor  Networks.  One  of  the  first  operating  systems  developed  specifically  for  Wireless 
Sensor  Networks  is  the  ‘Tiny’  operating  system,  known  as  TinyOS.  It  was  developed  at  the 
University  of  California  at  Berkeley  beginning  in  1999.  TinyOS  is  a  Linux  based  operating 
system  that  is  significantly  parsed  down  so  that  it  can  be  utilized  by  resource  limited  WSN 
nodes.  It  is  written  in  nesC,  which  is  a  variant  of  the  C  programming  language  and  is  ‘event 
driven,’  meaning  it  does  not  behave  like  many  other  operating  systems  when  dealing  with 
system  processes.  The  entire  operating  system  is  only  capable  of  performing  one  process 
at  a  time,  and  it  does  not  provide  a  means  to  prioritize  the  order  in  which  processes  run. 
TinyOS  utilizes  many  short  programs,  known  as  ‘event  handlers,’  to  handle  large  tasks  that 
the  node  may  be  asked  to  perform,  to  include  data  routing  [18]. 
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4  Related  Work 

Security  in  Wireless  Sensor  Networks  is  an  issue  of  critical  importance  to  the  development 
of  WSN  technology  as  a  whole.  A  significant  amount  of  research  has  been  invested  into 
solving  some  of  the  security  issues  that  Wireless  Sensor  Networks  face,  to  include  intrusion 
detection,  host  authentication,  and  data  sinkhole  mitigation.  In  [11],  authors  I.  Krontiris  et 
al.  propose  a  WSN  implementation  that  would  be  able  to  detect  sinkhole  attacks  in  Wireless 
Sensor  Networks  that  utilize  the  MintRoute  protocol  (a  routing  protocol  that  is  similar  to 
the  Collection  Tree  Protocol).  Such  a  system  could  enable  a  WSN  to  quickly  detect  an  attack 
and  trigger  its  defense  mechanisms  in  order  to  reduce  the  volume  of  data.  In  [6],  authors 
U.  Colesanti  and  S.  Santini  have  performed  an  in  depth  evaluation  of  the  Collection  Tree 
Protocol.  Their  research  explains  the  inner  workings  of  the  CTP  protocol  in  depth  and  tests 
the  Collection  Tree  Protocol  under  several  different  conditions. 

In  [10],  authors  J.  Deng  et  al.  enumerate  a  “Intrusion-tolerant  routing  protocol  for  Wireless 
Sensor  Networks:  INSENS.”  The  INSENS  protocol  aims  to  reduce  the  impact  an  adversary 
could  have  on  a  WSN  by  utilizing  a  number  of  security  features  to  include  light  cryptography, 
positive  host  identification,  and  network  analysis  at  the  base  station.  In  a  similar  line  of 
research,  T  Shu  et  al.  [8]  proposes  a  method  to  defeat  sinkhole  attacks  through  the  utilization 
of  ’’randomized  dispersive  routes.”  Under  this  method,  network  messages  are  broken  up  into 
many  ’shares’  that  are  distributed  throughout  the  network  before  they  converge  on  the  base 
station.  Once  a  set  number  of  shares  successfully  arrive  at  the  base  station,  the  data  from 
the  origin  node  can  be  reassembled.  Neither  of  the  routing  schemes  enumerated  above  utilize 
a  purely  routing  based  approach  to  mitigating  the  sinkhole  problem  in  WSNs.  Our  approach 
uses  only  changes  to  network  routing  in  order  to  avoid  sinkholes. 


5  Preliminary  Project  Work 

To  gain  a  better  understanding  of  Wireless  Sensor  Networks,  a  portion  of  project  time 
was  spent  working  with  actual  WSN  hardware.  Two  types  of  Wireless  Sensor  Network 
nodes  were  studied.  The  first  was  the  MICA2  Wireless  Measurement  System.  The  MICA2 
is  commercially  available  through  Crossbow  Technology.  The  MICA2  platform  is  small, 
measuring  only  2.25  x  1.25  x  1.0  inches  with  its  sensor  board  and  battery  pack  attached. 
The  unit  is  powered  by  two  standard  AA  batteries  and  has  a  battery  life  of  up  to  one  year 
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under  continuous  operation,  given  that  it  is  calibrated  to  use  a  power  saving  ’sleep’  mode 
that  reduces  the  number  of  transmissions  and  computations  that  the  node  performs  [17]. 
The  MICA2  has  only  128  KB  of  program  memory  and  the  processor  only  draws  8  mA  of 
current  while  active  and  only  15  /iA  in  sleep  mode.  The  transmitter  draws  27  mA  of  current 
when  transmitting  and  10  mA  while  in  receive  mode.  It  is  important  to  note  the  high  cost 
of  radio  transmission  in  terms  of  battery  drain.  The  second  WSN  hardware  platform  used  in 
project  work  was  the  IRIS  Wireless  Measurement  System.  The  IRIS  WSN  is  essentially  an 
improvement  on  the  MICA2  node,  and  is  very  similar  in  terms  of  size  and  capabilities  [16]. 
Both  WSN  node  platforms  run  the  TinyOS  operating  system  and  are  capable  of  implementing 
the  Collection  Tree  Protocol  (CTP).  TinyOS  applications  were  built,  compiled,  installed, 
and  run  on  both  the  MICA2  and  IRIS  hardware  platforms.  Due  to  the  limited  memory  and 
minimalist  premises  behind  Wireless  Sensor  Networks,  the  installation  of  new  programs  on 
WSN  nodes  becomes  a  somewhat  difficult  task.  In  order  to  implement  a  new  application 
on  the  MICA2  or  IRIS  platform,  the  entire  operating  system  must  be  recompiled  and  then 
reloaded  individually  on  to  each  sensor  node.  This  process  is  very  time  consuming  and  would 
generally  only  be  performed  as  part  of  a  major  operating  system  upgrade. 


6  Security  in  Wireless  Sensor  Networks 

Despite  the  immense  potential  of  sensor  networks,  the  low  cost  and  small  size  of  a  single 
sensor  node  severely  restricts  an  individual  node’s  computing  power  and  memory.  On  top 
of  this,  a  single  unit’s  lifetime  is  dictated  by  its  least  sophisticated  technology  -  the  battery. 
Any  activity  on  the  part  of  a  node,  in  terms  of  computation  and  transmission,  directly  affects 
the  lifetime  of  the  entire  unit.  In  addition,  while  the  computing  power  of  a  comparable  sized 
unit  may  increase  following  Moore’s  law1,  it  is  likely  that  more  inexpensive  productions  of  the 
same  unit  will  be  chosen  over  more  capable  components  [3].  Thus,  security  in  sensor  networks 
must  be  designed  and  implemented  with  energy  and  computing  efficiency  in  mind. 

In  addition  to  battery  and  computational  limitations,  wireless  sensor  networks  face  another 
unique  problem  -  node  capture.  In  typical  network  security  schemes,  it  is  assumed  that  the 
individual  hosts  (nodes)  are  safe  from  physical  capture  or  tampering.  In  WSNs,  nodes  may 
need  to  be  placed  in  hostile  and  or  easily  accessible  locations,  meaning  that  the  system  must 

1  Moore’s  law  is  the  observation  that  the  number  of  transistors  that  can  be  placed  on  a  circuit  doubles 
roughly  every  two  years 
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(a)  WSN  many-to-one  tree  struc¬ 
tured  routing 

Figure  1:  Comparision  of  Internet  routing  and  WSN  routing 

be  designed  so  that  the  capture  or  destruction  of  a  node  will  not  disrupt  the  overall  data 
transfer  capability  of  the  network  [4],  Additionally,  it  can  be  assumed  than  an  adversary 
will  be  able  to  extract  critical  data  from  a  captured  node.  She  may  then  be  able  to  use  this 
data  to  deny  service  to  the  network,  or  otherwise  exploit  the  network’s  security  system  [5]. 
Threats  on  WSNs  present  a  unique  challenge  in  that  many  traditional  computer  network 
security  solutions  do  not  directly  apply  to  a  WSN. 

On  the  Internet,  hosts  generally  communicate  in  a  one  to  one  fashion,  that  is,  one  host  uses 
the  network  to  communicate  with  only  one  other  specifically  addressed  host.  Wireless  sensor 
networks,  on  the  other  hand,  do  not  communicate  in  a  one  to  one  fashion.  Communication 
patterns  in  a  WSN  can  be  broken  down  into  three  basic  types:  many  to  one,  one  to  many, 
and  many  to  many  [3].  The  pattern  of  many  to  one  communication  stems  from  the  layout 
of  a  typical  wireless  sensor  network:  a  single  ‘base  station’  is  responsible  for  collecting  data 
from  many  different  nodes.  The  base  station  is  interested  in  aggregating  data  from  a  network 
composed  of  n  nodes,  where  n  1.  The  reverse  is  also  true,  resulting  in  a  one  to  many 
communication  pattern.  This  type  of  communication  occurs  when  the  base  station  wishes  to 
send  out  configuration  information  to  every  node  within  the  network,  resulting  in  a  multicast 
message  that  is  generated  at  the  base  station  of  the  network  and  is  desseminated  to  every 
node  in  the  network.  Lastly,  nodes  within  the  network  may  want  to  exchange  information 
with  other  nodes  within  the  network  (communication  that  excludes  the  base  station).  Such 
communication  may  occur  when  nodes  are  participating  in  the  exchange  of  local  routing 
information,  aggregating  data  within  a  neighborhood  of  nodes,  or  ‘voting’  in  an  effort  to 
detect  an  illegitimate  node  in  the  network  [1],  For  the  purpose  of  this  research,  we  will  focus 
on  WSN  communication  that  is  many  to  one. 


(b)  Internet  host-to-host  routing 
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The  host  to  host  nature  of  Internet  communication  generally  follows  a  simple  one  to  one 
communication  model,  where  a  host  is  capable  of  sending  out  messages  with  a  foreign  address 
and  receiving  data  that  has  been  addressed  to  it.  The  host  is  able  to  hand  off  a  packet  to 
a  router  that  has  a  wider  knowledge  of  the  network  topology.  The  router  then  sends  the 
packet  to  a  series  of  other  routers  that  guide  the  message  datagram  to  its  eventual  destination. 
Under  this  model,  a  host  is  only  expected  to  know  the  address  of  the  host  that  the  message 
will  be  sent  to.  Conversely,  in  the  role  of  a  receiver,  the  host  only  has  to  listen  for  packets 
that  are  addressed  to  it.  Routing  across  the  network  is  not  handled  by  hosts;  it  is  handled 
instead  by  routers  that  are  built  and  configured  specifically  for  that  task.  In  a  wireless  sensor 
network,  routing  is  handled  differently.  Every  node  within  a  wireless  sensor  network  can  be 
expected  to  act  as  a  receiving  node,  a  transmitting  node,  and  a  routing  node.  Depending 
on  the  layout  of  the  sensor  network  at  deployment  time,  the  topology  of  the  network  can 
leave  any  sensor  in  the  network  in  one  or  a  combination  of  all  three  of  the  roles  mentioned 
above.  This  difference  between  Internet  routing  and  WSN  routing  further  complicates  the 
application  of  Internet  based  networking  protocols  to  WSN  topologies. 

A  majority  of  secure  traffic  over  the  Internet  utilizes  the  Transmission  Control  Protocol. 
The  Transmission  Control  Protocol  utilizes  two  features  that  are  generally  not  implemented 
in  WSN  protocols  in  order  to  save  battery  life  (too  many  extra  transmissions).  The  first 
feature  is  that  of  ‘three  way  handshaking.’  Before  data  is  transmitted  between  two  hosts 
on  the  Internet,  TCP  ensures  that  there  is  a  valid  and  reliable  connection  between  the  two 
hosts.  The  sender  initiates  the  ‘handshake’  by  first  querying  the  receiver.  Upon  receipt  of 
the  query,  the  receiving  host  will  then  send  back  an  acknowledgement  (known  as  an  ACK), 
which  lets  the  originating  host  know  that  a  data  exchange  session  has  been  set  up  between 
the  sender  and  the  receiver.  Finally,  the  sending  host  sends  its  data  to  the  receiving  host 
(which  also  implicitly  serves  as  an  acknowledgement  -  the  third  part  of  the  handshake). 
Three  way  handshaking  allows  a  data  transmission  session  to  be  set  up  between  two  hosts 
before  actual  information  is  exchanged.  The  second  feature  of  TCP  is  an  extension  of  the  first 
-  the  use  of  acknowledgments.  The  Transmission  Control  Protocol  performs  accounting  on 
the  information  that  is  transfered  between  hosts.  Each  datagram  message  that  is  exchanged 
between  the  two  hosts  is  acknowledged  in  an  ACK  process  that  is  similar  to  the  three  way 
handshake  described  above.  If  transmitted  data  is  incomplete  or  lost,  TCP  will  retransmit 
the  data  to  ensure  its  accurate  and  complete  arrival.  Unfortunately,  most  Wireless  Sensor 
Network  protocols  do  not  implement  acknowledgements  due  to  the  extra  transmissions  that 
are  required  to  ensure  data  delivery  [15]. 
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Internet 

Wireless  Sensor  Networks 

One  to  One  communication 
Assumption  of  host’s  physical  security 
Strong  cryptography 
Transmission  Acknowledgements 

Many  to  One  Communication 
No  assumption  of  node  security 
Weak  or  no  cryptography 
Little  or  no  acknowledgements 

Table  1:  Comparison  of  differences  between  Internet  and  WSN  communication  protocols 

7  Wireless  Sensor  Network  Topology 


In  order  to  understand  the  establishment  of  routing  protocols  in  wireless  sensor  networks,  we 
must  first  understand  the  properties  of  the  network  graph.  We  define  the  network  graph  to 
be  the  set  of  all  WSN  nodes,  to  include  the  base  station  (the  base  station  is  also  commonly 
referred  to  as  the  ‘root’  or  ‘sink’  of  the  network).  We  assume  that  the  uninitialized  network 
graph  is  a  connected,  undirected  graph,  meaning  that  every  node  in  the  network  is  adjacent 
to  at  least  one  other  node  in  the  network  (they  can  communicate  wirelessly).  Please  reference 
Figure  2  and  Figure  3  for  a  further  visual  explanation. 


o 

Base  Station  (root) 

• 

Network  Node 

Network  Link  (edge) 

Transmission  Half-radius 

Transmitting  Node 

• 

Sinkhole  Node 

• 

Bridge  Node 

(a)  Key  for  network  diagrams  (b)  An  uninitialized  WSN  network  with  nodes 

and  a  base  station 

Figure  2 


Adjacency  in  a  wireless  sensor  network  is  dictated  by  the  radius  of  communication  Rc  and 
is  best  described  as  a  unit  disk  graph :  each  node  lies  at  the  center  of  a  unit  disk  (with  unit 
radius  r),  and  an  edge  is  defined  whenever  two  disks  overlap.  For  sensor  networks,  we  then 
have  r  =  Rcj 2  [9].  This  requirement  on  the  edges  imposes  a  sense  of  distance  in  the  graph. 
It  is  important  to  note  that  arbitrary  edge  sets  are  not  possible;  in  particular,  edges  that 
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(a)  Unit  disk  graph  with  radii  ‘r.’  Overlapping  ‘r’ 
indicates  a  possible  network  edge 


(b)  All  possible  connections  of  the  network  graph, 
with  higher  quality  network  connections  represented 
in  bold 


Figure  3:  An  arbitrary  network  graph  with  possible  network  connection  edges  given  the  ‘r’ 
of  each  node 


exceed  2 r  in  length  cannot  occur,  so  widely  distributed  edges  cannot  be  connected  directly, 
and  hence  must  be  connected  by  a  path  through  the  graph  as  shown  in  Figure  3. 

The  tree  structured  routing  utilized  by  wireless  sensor  networks  is  established  through  the 
utilization  of  some  sort  of  path  metric.  In  general,  the  selection  of  edges  is  based  on  the  ‘best 
path’  between  two  nodes,  given  the  path  metric.  The  Collection  Tree  Protocol  (CTP)  seeks 
to  find  the  best  path  to  the  root  node  by  transmitting  as  few  times  as  possible  (it  seeks  to 
transmit  over  the  most  reliable  path  to  the  base  station).  This  path  metric  in  CTP  is  known 
as  the  ETX  value  which  stands  for  ‘Expected  Transmissions’).  The  ETX  value  represents 
the  predicted  number  of  node  transmissions  that  will  need  to  occur  for  a  message  to  reach 
the  base  station.  The  ETX  value  is  established  during  network  setup  and  is  based  on  the 
number  of  transmissions  that  are  necessary  to  successfully  transmit  a  routing  query  message 
between  two  nodes.  An  optimal  ETX  value  between  any  set  of  nodes  is  ‘1,’  as  only  one 
transmission  is  required  to  successfully  transmit  the  data.  The  base  station  is  a  special  case, 
as  it  does  not  need  to  transmit  in  order  to  communicate  with  itself,  thus,  the  base  station 
has  an  ETX  value  of  ‘0.’  Every  other  node  in  the  network  will  have  an  ETX  value  that  is 
greater  than  ‘1,’  and  the  ETX  value  of  any  node  in  the  network  will  the  be  the  sum  of  the 
ETX  value  of  its  parent  and  the  ETX  value  of  the  link  between  the  aforementioned  node 
and  its  parent.  A  valid  data  transmission  over  a  routing  tree  using  CTP  is  shown  in  Figure 
4 
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We  model  a  sensor  network  as  a  unit  disk  graph  G(V,  E),  composed  of  the  set  V,\V\  =  N  of 
vertices  (sensors)  and  the  set  E  of  edges  determined  by  radio  reception. 

The  tree  T(V,E')  C  G(V,E)  is  defined  by  the  TinyOS  Collection  Tree  Protocol,  rooted  at 
the  base  station.  We  will  usually  denote  this  tree  simply  as 

We  make  the  following  assumptions  about  the  sensor  network: 

•  Each  sensor  node  is  identical  in  terms  of  initial  battery  life,  transmitter  and  receiver 
capacity. 

•  Only  one  base  station  is  placed. 

•  Once  placed,  the  sensors  are  fixed. 

•  The  sensors  are  uniformly  distributed;  for  any  sensor  v  and  neighborhood 


Nv  4  {Vi  | 

we  have,  on  average,  \NV\  =  k  for  any  v 
simple  analysis. 

dr(v,Vi)  <  rradio} 

G  G,  with  sufficient  small  variance  to  allow  for 

• 

• 

• 

• 

• 

4 
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•  •  •  •  \  #  • 

•  •  •  •  \  #  • 

9  *• — 4  *  •  • 

9  •• - 4  #  •  4 

•  •  u  • 

r-k 

#  •./  •  *  • 

*  •  •  •  • 

•  •  •  • 

•  i 

•  •  •  • 

•  •  *  •  #  •  • 

•  • - *  •  #  •  • 

(a)  The  green  node  is  attempting  to  transmit  data  (b)  The  data  follows  the  path  directed  by  the  net- 
to  the  base  station  work  tree  and  successfully  reaches  the  base  station 

Figure  4:  Normal  data  routing  in  a  WSN 
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Figure  5:  A  depiction  of  the  risk  gradient,  where  nodes  in  green  represent  a  low  risk  of  data 
loss, and  nodes  in  red  represent  a  high  risk  of  data  loss 

8  Threat  Model 

The  essential  function  of  a  sensor  network  is  to  report  data.  The  data  flows  across  the 
deployment  region,  routed  via  the  minimum  weight  spanning  tree  (MST).  Each  sensor  routes 
data  along  the  minimum  weight  path  to  a  base  station  that  acts  as  a  root  node  (we  will  use 
‘node’  and  ‘sensor’  interchangeably  when  there  is  no  confusion).  For  the  purpose  of  our 
research,  we  assume  that  the  base  station  is  secure  and  has  not  been  tampered  with  by  an 
adversary.  This  is  a  reasonable  assumption,  as  the  compromise  of  the  base  station  would 
allow  the  adversary  to  control  the  entire  WSN  and  serves  to  trivialize  the  avoidance  of  a 
routing  sinkhole,  which  is  our  project  focus. 

A  sensor  node  that  has  been  compromised  by  an  attacker  can  act  as  a  ‘sinkhole’  and  ma¬ 
nipulate  all  network  data  that  is  forwarded  to  it.  Our  research  focuses  on  an  adversary  that 
controls  a  sinkhole  in  the  network  and  chooses  to  drop  all  network  data  that  is  forwarded 
to  it.  In  particular,  the  adversary  influences  the  routing  so  that  it  maximizes  the  amount  of 
traffic  flowing  to  it.  This  is  the  ‘sinkhole’  attack  and  is  the  focus  of  this  work.  We  assume 
that  the  adversary  is  able  to  completely  compromise  one  sensor.  The  adversary  will  then 
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have  the  ability  to  influence  how  the  minimum  spanning  tree  is  established.  A  compromised 
sensor  would  be  able  to  advertise  a  favorable  metric  so  as  to  be  included  in  the  tree  as  a 
routing  node  instead  of  a  leaf  node.  We  assume  that  the  adversary  may  enhance  the  sensor 
to  support  this  metric.  In  this  way,  the  compromised  sensor  will  receive  traffic  from  down¬ 
stream  nodes  for  examination  (whereas  a  leaf  node  does  not  have  downstream  nodes).  The 
adversary  may  achieve  her  goal  through  a  combination  of  positioning  herself  close  to  the 
base,  or  influencing  how  the  minimum  spanning  tree  is  established  through  fraudulent  route 
costs,  wherein  a  compromised  sensor  will  advertise  a  favorable  metric  so  as  to  be  included  in 
the  tree  as  a  routing  node  instead  of  a  leaf  node.  We  assume  that  the  adversary  only  drops 
traffic.  This  means  that  the  adversary  will  try  to  influence  as  much  traffic  as  possible  by 
positioning  herself  close  to  the  base,  resulting  in  a  “risk  gradient”  where  nodes  that  are  far 
from  the  base  are  less  likely  to  be  compromised,  as  shown  in  Figure  5. 
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(a)  The  green  node  is  attempting  to  transmit  data  (b)  The  data  follows  the  path  directed  by  the  net- 
to  the  base  station  in  the  presence  of  a  sinkhole  work  tree  and  is  intercepted  by  the  sinkhole  before 

it  reaches  the  base  station 

Figure  6:  WSN  Routing  Example 


The  position  of  a  sinkhole  node  in  the  network  will  affect  the  impact  that  the  sinkhole  is 
able  to  have  on  the  network  as  a  whole.  In  a  network  that  utilizes  tree  structured  routing, 
every  node  in  the  network  must  rely  on  its  parent  to  forward  data  closer  to  the  base  station. 
In  a  sense,  tree  structured  routing  creates  a  communication  chain  that  can  be  broken  by 
removing  a  single  link.  The  closer  the  broken  link  is  to  the  base  station,  the  more  links 
that  will  be  severed  from  the  base  station.  This  idea  ties  into  the  risk  gradient  depicted  in 
Figure  5.  If  a  sinkhole  node  happens  to  be  positioned  at  the  root  of  a  subtree,  then  the 
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sinkhole  will  be  able  to  disconnect  that  entire  subtree  from  the  base  station.  Depending  on 
the  distribution  of  nodes  in  the  sensor  network,  this  could  mean  that  a  large  geographic  area 
of  the  sensor  network  will  be  unable  to  report  its  data. 
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(a)  A  WSN  with  a  sinkhole,  given  the  green  trans-  (b)  The  sinkhole  is  at  the  root  of  the  subtree,  which 
mitting  node  and  the  red  sinkhole  effectively  cuts  off  the  rest  of  that  subtree  from  the 

network 


Figure  7:  The  effect  of  a  sinkhole  in  a  WSN 


9  Description  of  Protocols 

9.1  Generic  Protocol  Description 

In  order  to  better  describe  the  complex  distributed  protocols  enumerated  in  this  project,  we 
will  first  define  an  abstract  distributed  protocol.  Our  abstract  scenario  will  describe  barking 
dogs  in  a  neighborhood.  Our  distributed  protocol  will  give  instructions  for  a  dog  to  execute 
once  an  event  occurs.  Each  dog  in  the  neighborhood  executes  the  same  protocol. 

When  (I  hear  another  dog  bark) 

Then 

1  I  bark  once 

This  abstract  protocol  can  be  used  to  imagine  how  a  WSN  initializes  the  routing  infrastruc¬ 
ture  of  the  network.  A  dog  that  is  in  the  center  of  his  neighborhood  would  initiate  a  bark. 
This  bark  would  then  move  outward  towards  the  edges  of  the  neighborhood  until  every  dog 
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in  the  neighborhood  is  barking.  The  CTP  protocol  initiates  itself  in  a  similar  manner,  except 
that  beacons  are  used  instead  of  barks,  and  that  many  of  the  events  are  triggered  by  timers 
in  order  to  reduce  the  number  of  transmissions  required  by  each  node. 

9.2  The  Collection  Tree  Protocol 

The  Collection  Tree  Protocol  (CTP)  is  the  standard  protocol  that  our  project  aims  to  improve 
upon.  CTP  attempts  to  transmit  data  over  the  lowest  cost  path.  In  simple  terms,  the  ‘cost’  of 
a  spanning  tree  is  the  sum  over  all  edges  of  the  transmission  quality.  This  quality  is  captured 
by  the  Expected  Transmissions  value  (ETX),  and  is  used  by  CTP  for  the  construction  of 
the  minimal  spanning  tree.  From  the  description:  “CTP  is  a  tree-based  collection  protocol. 
Some  number  of  nodes  in  a  network  advertise  themselves  as  tree  roots.  Nodes  form  a  set  of 
routing  trees  to  these  roots.  CTP  is  address-free  in  that  a  node  does  not  send  a  packet  to  a 
particular  root:  instead,  it  implicitly  chooses  a  root  by  choosing  a  next  hop.  Nodes  generate 
routes  to  roots  using  a  routing  gradient.”  [7]  We  seek  to  expand  CTP  so  that  it  supports 
bridge  discovery.  The  challenge  is  to  implement  our  changes  to  the  source  code  in  such  a 
way  that  does  not  break  the  protocol  or  significantly  add  to  the  complexity  of  the  protocol 
in  terms  of  battery  cost  (extra  transmissions  and  computations).  We  are  most  concerned 
with  taking  advantage  of  the  distributed  nature  of  the  protocol  so  as  to  keep  the  routing 
complexity  on  an  individual  node  to  a  minimum. 

Our  modification  of  CTP  will  occur  inside  the  routing  engine.  We  will  focus  on  four  functions 
within  the  code  that  have  important  roles  in  initializing  routing  within  CTP.  We  refer  to 
these  functions  as  event  handlers ,  as  they  are  executed  when  a  specific  routing  related  event 
occurs.  These  event  handlers  allow  CTP  to  build  and  update  the  routing  tables2  necessary 
for  the  protocol  to  successfully  implement  tree  structured  routing.  The  four  event  handlers 
we  will  modify  are:  the  Send  Beacon  Handler,  the  Beacon  Message  Received  Handler,  the 
Table  Update  Handler,  and  the  Update  Route  Handler.  We  also  describe  the  Beacon  Timer 
Handler,  as  it  directly  influences  two  of  the  other  event  handlers  that  we  modify  within  the 
routing  engine. 


2  CTP  stores  the  information  of  neighboring  nodes  in  a  data  structure  know  as  a  Routing  Table.  By 
default,  this  data  structure  is  limited  to  10  entries. 
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Beacon  Timer  Handler 


Source  code3: 


When  (The  send  beacon  timer  expires) 

Then 


1  Reset  send  beacon  timer 

2  Send  event  to  Send  Beacon  Handler 

3  Send  event  to  Update  Route  Handler 


void  CtpRoutingEngine  :  :  event .BeaconTimer .fired  (){ 
if(radioOn  &&  running)! 
if  (!tH  as  Passed)! 

post _updateRouteTask  ( )  ; 
post _sendBeaconTask  ( )  ; 
trace  ()«”  Beacon^ timer  ^  f i  r ed  .  ”  ; 
remaininglnt erval  ()  ; 

} 

else  ! 

decay Interval () ; 

} 

} 

} 


Send  Beacon  Handler 

When  (A  send  beacon  event  is  received) 

Then 

1  Send  a  beacon  with  my  information:  ID,  Parent  ID,  ETX 

Source  code: 

void  CtpRoutingEngine  :  :  sendBeaconTask  ()  ! 
error _t  eval  ; 
if (sending)! 

return ; 

} 

beaconMsg— >set Options  (0)  ; 

if  (  cfe  — >command_Ct  p  Congest  ion  _is  Conges  ted  ( )  )  ! 

beaconMsg— >setOptions  (beaconMsg— >getOptions  ()  |  CTP_OPT_ECN)  ; 

} 

beaconMsg— >set Parent  (routelnfo  .  parent)  ; 
if ( state_is_root  )! 

beaconMsg— >setEtx  (routelnfo  .etx)  ; 

} 


3 A  complete  listing  of  all  source  code  is  printed  in  the  appendix 
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else  i  f  (  rout elnfo  .  parent  =  INVALID _ADDR)  { 
beaconMsg— >setEtx  (  routelnfo  .  etx  )  ; 

beaconMsg— >setOptions  (beaconMsg— >getOptions  ()  |  CTP.OPTJPULL)  ; 

}  else  { 

beaconMsg— >set Etx  (  routelnfo  .  etx  +  le  — >command_LinkEst imator_get LinkQuality  ( 
routelnfo  . parent) )  ; 

} 

trace  ( )«”  sendBeaconTask^— ^parent  :  V’ <<(int )  beaconMsg— >get Parent  ( ) 

«”  ^etx  :  V’«(int )  beaconMsg— >getEtx  ()  ; 

beaconMsg— >get Rout inglnteract ionControl  ()  .  lastHop  =  self  ;  //  ok 
eval  =  le— >command_Send_send  (AM_BROADCAST.ADDR,  beaconMsg— >dup  ()  )  ; 

if  (eval  =  SUCCESS)! 

//  statistics 

collect  Output  (”  Ctp„Beacons”  ,”Tx”  )  ; 

sending  =  true  ; 

}  else  if  (eval  =  EOFF)  { 
radioOn  =  false  ; 

trace  ()«”  sendBeaconTask^—^ running  :  ^”«running«”  ..radio  On  :  ^”«radioOn  ; 

} 

} 

Beacon  Message  Received  Handler 

When  (A  beacon  message  is  received) 

Then 

1  Read  neighbor  beacon  information:  ID,  Parent  ID,  ETX 

2  Check  parent  ID 

3  If  parent  ID  matches  my  own  ID,  then  stop 

4  Calculate  message  ETX  using  the  link  estimator 

5  Calculate  new  ETX  by  adding  neighbor  ETX  to  message  ETX 

6  Send  event  to  Table  Update  Handler 

Source  code: 

void  CtpRoutingEngine  :  :  event  .BeaconReceive .receive  ( cPacket  *  msg)  { 

Enter  .Method  (”  event_BeaconReceive_receive”  )  ; 
am.addr _t  from  ; 
bool  congested  ; 

//  statistics 

collect  O ut put  ( ”  Ctp^Beacons”  ,”Rx”  )  ; 
from  =  command_AMPacket_source  (msg)  ; 

CtpBeacon*  rcvBeacon  =  check_and_cast  <CtpBeacon*>(msg)  ; 
congested  =  command_CtpRoutingPacket_getOption  (msg  , CTP_OPT_ECN)  ; 


19 


trace  ()«”  Be  aeon  Receive  .  receive  „from„”«(int )  from«”  ^  [  parent  : 
<<(int )  rcvBeacon— >get Parent  ()«”  ^etx  :  ^”«(int )  rcvBeacon— >getEtx  () 
«”  ]  ”  ; 


//update  neighbor  table 

i  f  (  rcvBeacon— >get  Parent  ( )  !  =  INVALIDd\DDR)  { 

//  If  this  node  is  a  root,  request  a  forced  insert  in  the  link 
//  estimator  table  and  pin  the  node. 
i  f  (  rcvBeacon— >getEtx  ()  =  0){ 

trace  ( )«”  from  ^a^  root  ,  ^inserting^if  ^not  ^in  stable 
«”  my_ll_addr  :  ^”«my _ll_addr  ; 

le  — >command_LinkEstimator_insertNeighbor  (from)  ; 
le  — >command_LinkEstimator_pinNeighbor  (from)  ; 

} 

routingT ableUpdateEntry  ( 

from  ,  rcvBeacon— >getParent  ( )  , 
rcvBeacon— >getEtx  ( )  ; 

command_CtpInfo_setNeighborCongested  (from  ,  congested  )  ; 

} 

i  f  (  command_CtpRoutingPacket_getOption  (msg  ,  CTP.OPTJPULL)  ) 
reset  Interval ()  ; 

delete  msg  ; 


Tabic  Update  Handler 

When  (A  table  update  event  is  received) 

Then 

1  Read  new  neighbor  information:  ID,  Parent  ID,  ETX 

2  If  routing  table  is  full,  then  stop 

3  Add  new  neighbor  information  to  the  routing  table 

Source  code: 

error.t  CtpRoutingEngine  :  :  rout ingTableUpdateEntry  ( 
am.addr _t  from  , 
am_addr_t  parent  , 
uintl6_t  etx{ 

uint 8_t  idx  ; 
uintl6_t  linkEtx  ; 

linkEtx  =  evaluateEtx  ( le  — >command_LinkEst imator_get LinkQuality  ( from )  )  ; 

idx  =  rout  ingTableFind  (  from )  ; 
if(idx  =  rout  ingTableSize  )  { 

trace  ( )«”  rout  ingTableUpdateEntry  ^FAIL  ,„table-full”  ; 
return  FAIL; 


} 
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else  if(idx  =  routingTable  Act  ive  )  { 

if  (passLinkEtxThreshold(linkEtx)  ){ 

rout  ingTable  [  idx  ].  neighbor  =  from; 
rout  ingTable  [  idx  ].  info  .  parent  =  parent; 
routingTable  [  idx  ].  info  .  etx  =  etx  ; 
rout  ingTable  [  idx  ].  info  .  haveHeard  =  1; 
rout  ingTable  [  idx  ].  info  .  congested  =  false; 
rout  ingT  able  Act  ive ++; 

trace  ( )«”  routingTableUpdate Entry -—-OK,  -new- entry”  ; 

} 

else 

trace  ()«”  routingTableUpdate  Entry -—-Fail  ,  -link-quality  (” 
«(int )  linkEtx«”  )  -below -threshold ”  ; 


} 

else  { 

//found,  just  update 
rout  ingTable  [  idx  ].  neighbor  =  from; 
rout  ingTable  [  idx  ].  i  n  fo  .  parent  =  parent; 
rout  ingTable  [  idx  ].  i  n  fo  .  etx  =  etx; 
rout  ingTable  [  idx  ].  i  n  fo  .  haveHeard  =  1; 

trace  ()«”  routingTableUpdateEntry  -—  -OK,  -updated -entry ”  ; 

} 

return  SUCCESS; 

} 

Update  Route  Handler: 

When  (An  update  route  event  is  received) 

Then 

1  Read  all  neighbor  information  from  the  table:  ID,  Parent  ID,  ETX 

2  Pick  the  neighbor  with  the  best  ETX 

3  Set  that  neighbor  as  the  new  parent 

Source  code: 

void  CtpRoutingEngine  :  :  updateRouteTask  ()  { 
uint8_t  i ; 

routing_t able_entry *  entry; 
routing_t able_entry *  best; 
uintl6_t  minEtx ; 
uintl6_t  currentEtx  ; 
uintl6_t  linkEtx  ,  pathEtx ; 

if  (  s t  a t  e _i s  _r o o t  ) 

return  ; 

best  =  NULL; 

/*  Minimum  etx  found  among  neighbors  ,  initially  infinity  */ 
minEtx  =  MAXJMETRIC; 
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/*  Metric  through  current  parent,  initially  infinity  */ 
currentEtx  =  MAX  JMETRIC ; 

trace  ( )«”  updateRouteTask”  ; 

/*  Find  best  path  in  table  ,  other  than  our  current  */ 
for(i  =  0;  i  <  routingTableActive;  i++){ 
entry  =  &rout ingTable  [  i  ]  ; 

//  Avoid  bad  entries  and  1—hop  loops 
i  f  (  entry  — >info  .  parent  =  INVALID^ADDR  || 
entry— >info  .  parent  =  my_ll_addr){ 

trace  ()«”  routingTable  [”«(int )  i«”  ]  :  -neighbor  :  -  [  id  :  -” 

«(int )  entry— >neighbor«”  -parent  :  -”«entry  — >info  .  parent 
«”  --etx  :  -NO -ROUTE]  ”  ; 

continue  ; 

} 

//  Compute  this  neighb  or  ’s  path  metric 

linkEtx  =  evaluateEtx  ( le  — >command_LinkEstimator_getLinkQuality  (  entry  — >neighbor  )  )  ; 

trace  ()«”  routingTable  [”«(int )  i«”  ]  :  -  neighbor  :  -  [id  :  -”<<(int )  entry  — >neighbor 
«”  -parent  :  -”«entry  — >info  .  parent «”  --etx  :  -”«(int )  linkEtx 
«”  ]  ”  ; 


pathEtx  =  linkEtx  +  entry  — >info  .  etx  ; 

/*  Operations  specific  to  the  current  parent  */ 
i  f  (  entry  — >neighbor  =  routelnfo  .  parent )  { 
trace  ( )«”  already -  parent”  ; 

currentEtx  =  pathEtx; 

/*  update  routelnfo  with  parent’s  current  info  */ 

routelnfo . etx  =  entry  — >info . etx ; 

routelnfo  .  congested  =  entry— >info  .  congested  ; 

continue  ; 

} 

/*  Ignore  links  that  are  congested  */ 
i  f  (  entry —>info  .  congested) 

continue  ; 

/*  Ignore  links  that  are  bad  */ 
if  (!  passLinkEtxThreshold(linkEtx)){ 

trace  ( )«”  did  -  not  -  pass-threshold  .  ”  ; 

continue  ; 

} 

if  (pathEtx  <  minEtx){ 
minEtx  =  pathEtx  ; 
best  =  entry  ; 
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} 

} 

i  f  ( minEtx  !=  MAXX1ETRIC)  { 

if  (currentEtx  =  MAX_METRIC  || 

(  routelnfo  .  congested  &&;  (minEtx  <  (  rout  elnfo  .  etx  +  10)))  | 

minEtx  +  PARENT_SWTTCH_THRESHOLD  <  currentEtx ){ 

parent  Changes++; 

trace  ()«”  Changed^parent  .  Mrom^”<<(int )  routelnfo  .  parent «”  ^to^” 
«(int )  best  — >neighbor  ; 

le  — >command_LinkEstimator_unpinNeighbor  (  routelnfo  .  parent )  ; 

le  — >command_LinkEstimator_pinNeighbor  (  best  — >neighbor  )  ; 

le  — >command_LinkEstimator_clearDLQ  (  best  — >neighbor  )  ; 

routelnfo  .  parent  =  best  — >neighbor  ; 

routelnfo  .  etx  =  best  — >info  .  etx  ; 

routelnfo  .  congested  =  best  — >info  .  congested  ; 

} 

} 

else  i  f  (!  j  ust Evict ed 

currentEtx  =  MAXMETRIC  && 
minEtx  !=  MAXMETRIC) 
signal_Routing_routeFound  ()  ; 

justEvicted  =  false; 


9.3  Protocol  Modification 

The  Collection  Tree  Protocol  (CTP),  which  is  described  in  detail  above,  is  used  as  the  basis 
for  our  routing  protocol.  Our  work  has  added  the  awareness  of  principle  subtrees  to  CTP. 
Our  changes  to  CTP  are  described  below. 

Our  protocol: 


Primary  Subtree 
Identification 

Bridge 

Primary  Subtree 

and  Assignment 

Discovery 

Routing 
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(a)  Directed  tree  utilized  by  the  network  protocol 
for  data  forwarding 


(b)  The  different  subtrees  of  the  entire  network  tree 
are  highlight  in  different  colors 


Figure  8:  Network  tree  topology  that  illustrates  the  multiple  principle  subtrees  of  the  entire 
network 


Principle  Subtree  Identification  and  Assignment 

•  After  CTP  network  setup  is  complete,  determine  which  nodes  have  the  base  station  as 
a  parent 

•  Identify  these  nodes  as  the  roots  of  the  principle  subtrees 

•  Each  of  these  root  nodes  receives  an  index  value  assigned  by  the  base  station 

•  The  subtree  roots  then  disseminate  their  principle  subtree  index  (PST  ID)  to  the 
members  of  their  principle  subtree 

Bridge  Discovery  -  reference  Figure  9 

•  Each  node  in  the  network  queries  its  list  of  neighbors  and  obtains  their  PST  ID 

•  If  a  node  has  a  neighbor  with  a  PST  ID  value  different  from  its  own,  then  the  neighbor 
node  is  a  bridge 

•  Each  bridge  in  a  principle  subtree  Tj,  with  index  j,  that  contains  the  sinkhole  ‘re-runs’ 
the  CTP  tree  establishment  protocol  by  advertising  a  very  low-cost  route  to  the  base. 
This  advertisement  is  limited  to  only  those  sensor  nodes  in  Tj,  and  results  in  multiple 
CTP  tree  roots  with  routes  to  the  base.  Sensor  node  routing  tables  are  modified  to  keep 
track  of  whether  next  hops  (to  parents)  are  routed  towards  bridges,  giving  nodes  the 
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chance  to  pick  a  next  hop  at  random  from  among  the  available  bridges.  This  approach 
is  feasible  since  we  have  implemented  the  ability  for  sensor  nodes  to  determine  their 
subtree  index  as  part  of  the  bridge  discovery  simulations. 

V  -  vV  L  \  /  -J 

• 

• 

• 

• 

•  • 

• 

4 

•  •  •  •  \  \  •  * 

•  •  •  •  \  •  • 

-  V  \  • 

• 

• 

• 

• 

• 

i 

• 

•  -  •  \  v  7  v  \ 

• — ■ ■  v 

•  /  * — 

ttfCj  •  Px  ± 

•  •  •  •  « 

« 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

i 

i 

i 

• 

• 

• 

• 

• 

• 

(a)  The  transmitting  node  has  multiple  neighbors  (b)  One  neighbor  of  the  transmitting  node  is  a  bridge 
that  it  can  potentially  forward  data  to,  represented  to  another  subtree,  which  is  indicated  by  the  blue 
by  the  blue  nodes  node  and  its  dashed  line  to  the  alternate  subtree 


Figure  9:  Bridge  node  identification 


Principle  Subtree  Routing  -  reference  Figure  10 

•  If  a  node  suspects  that  there  is  a  sinkhole  in  its  subtree,  it  chooses  a  bridge  node  and 
routes  in  that  direction  (adding  the  bridge  node  ID  to  the  packet  to  ensure  proper 
downstream  routing) 

•  A  bridge  node  that  receives  data  from  a  different  subtree  will  forward  the  data  to  the 
base  station  via  the  Collection  Tree  Protocol 
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(a)  The  transmitting  node  is  attempting  to  transmit 
data  to  the  base  station  in  the  presence  of  a  sinkhole 


(b)  The  transmitting  node  routes  data  to  a  bridge 
node,  who  then  routes  the  data  to  a  different  subtree. 
Once  in  a  different  subtree,  the  data  is  routed  to  the 
base  station  via  the  normal  directed  network  tree 


Figure  10:  Principle  Subtree  Routing  using  a  bridge  between  principle  subtrees 


Our  changes  to  the  CTP  protocol  occur  within  four  event  handlers  that  are  a  part  of  the 
CTP  routing  engine:  the  Send  Beacon  Handler,  the  Beacon  Message  Received  Handler, 
the  Table  Update  Handler,  and  the  Update  Route  Handler.  We  modify  these  functions 
so  as  to  implement  bridge  descovery  through  the  addition  of  a  priniciple  subtree  index 
(PST_ID).  Inclusion  of  the  PST_ID  in  the  protocol  will  only  add  two  bytes4  to  each  beacon 
message. 

Beacon  Timer  Handler5 

When  (The  send  beacon  timer  expires) 

Then 

1  Reset  send  beacon  timer 

2  Send  event  to  Send  Beacon  Handler 

3  Send  event  to  Update  Route  Handler 


4One  byte  is  equal  to  8  bits. 

5We  do  not  modify  this  event  handler;  however,  it  is  important  to  understand  it’s  function  as  it  is 
responsible  for  triggering  the  Send  Beacon  Handler  and  the  Update  Route  Handler. 
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Send  Beacon  Handler6 

When  (A  send  beacon  event  is  received) 

Then 

1  Send  a  beacon  with  my  information:  ID,  Parent  ID,  ETX,  PST_ID 

Source  code: 

void  CtpRoutingEngine  :  :  sendBeaconTask  ( )  { 
er r or _t  eval  ; 
i f ( sending  )  { 

return ; 

} 

beaconMsg— >set Options  (0)  ; 

if  (  cfe  — >command_Ct  p  Congest  ion  _is  Congested  ( )  )  { 

beaconMsg— >setOptions  (beaconMsg— >getOptions  ()  |  CTP_OPT_ECN)  ; 

} 

beaconMsg— >set Parent  (routelnfo  .  parent)  ; 
if ( state_is_root  ){ 

beaconMsg— >setEtx  (  routelnfo  .  etx  )  ; 

} 

else  i  f  (  rout elnfo  .  parent  =  INVALID  _ADDR)  { 
beaconMsg— >set  Etx  (routelnfo  .etx)  ; 

beaconMsg— >setOptions  (beaconMsg— >getOptions  ()  |  CTP_OPTJPULL)  ; 

}  else  { 

beaconMsg— >setEtx  (  routelnfo  .  etx  +  le  — >command_LinkEstimator_get LinkQuality  ( 
routelnfo . parent) )  ; 

} 

beaconMsg— >set  Pst  Id  (  my.pstld  )  ; 

trace  ( )«”  sendBeaconTask parent  :  <<(int )  beaconMsg— >get Parent  ( ) 

«”  -etx  :  -”«(int )  beaconMsg— >getEtx  ()  ; 

beaconMsg— >get Routinglnteract ionControl  ()  .  lastHop  =  self  ;  //  ok 
eval  =  le  — >command_Send_send  (AM_BROADCAST_ADDR,  beaconMsg— >dup  ())  ; 


if  (eval  =  SUCCESS)  { 

//  statistics 

collect  Output  (”  Ctp-Beacons”  ,”Tx”)  ; 

sending  =  true  ; 

}  else  if  (eval  =  EOFF)  { 
radioOn  =  false  ; 

trace  ()«”  sendBeaconTask^—  ^running  :  -”<<running<<’’  -  radio On  :  -”«radioOn  ; 

} 

} 


6  Changes  to  the  original  CTP  protocol  are  printed  in  italics 
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Beacon  Message  Received  Handler 

When  (A  beacon  message  is  received) 

Then 

1  Read  neighbor  beacon  information:  ID,  Parent  ID,  ET 'X.,PST_ID 

2  Check  parent  ID 

3  If  parent  ID  matches  my  own  ID,  then  stop 

4  If  parent  ID  is  root,  set  my  PST_ID  to  my  ID 

5  If  parent  is  not  root,  set  my  PST  ID  to  my  parent’s  PS  TDD 

6  Calculate  message  ETX  using  the  link  estimator 

7  Calculate  new  ETX  by  adding  neighbor  ETX  to  message  ETX 

8  Send  event  to  Table  Update  Handler 

Source  code: 

void  CtpRoutingEngine  :  :  event _BeaconReceive_receive  (cPacket*  msg){ 

Enter  .Method  (”  event.BeaconReceive  .receive”  )  ; 
am.addr.t  from  ; 
bool  congested  ; 

//  statistics 

collect  Output  ( ”  Ctp^Beacons”  ,”Rx”  )  ; 
from  =  command.AMPacket.source  (msg)  ; 

CtpBeacon*  rcvBeacon  =  check.and.cast <CtpBeacon*>(msg)  ; 
congested  =  command.CtpRoutingPacket.getOption  (msg  , CTP_OPT_ECN)  ; 

trace  ()«”  BeaconReceive  .  receive  Mrom V’ <<(int )  from«”  ^  [  parent  : 

«(int )  rcvBeacon— >get Parent  ( )«”  ^etx  :  V’ «(int )  rcvBeacon— >getEtx  ( ) 

«”  ^pstld  :  <<(int )  rcvBeacon->get  Pst  Id  ()«”  ]  ”  ; 

//update  neighbor  table 

i  f  (  rcvBeacon— >getParent  ( )  !=  INVALID _ADDR)  { 

//  If  this  node  is  a  root  ,  request  a  forced  insert  in  the  link 
//  estimator  table  and  pin  the  node. 
if  (rcvBeacon— >getEtx  ()  =  0){ 

trace  ( )«”  from  ^a^  root  ,  Mnserting^if  ^not  Mn  ^  t  able  V’ 

«”  my.ll.addr  :  u”«my .ll.addr  ; 

le  — >command_LinkEstimator_insertNeighbor  (from)  ; 
le  — >command_LinkEstimator_pinNeighbor  (from)  ; 

//  since  i  hear  root,  i  Jm  the  root  of  a  principle  subtree 
my.pstld  =  my.ll.addr  ; 

} 

i  f  ( rcvBeacon— >getEtx  ( )  =  0) 
routingTableUpdateEntry  ( 

from  ,  rcvBeacon— >getParent  ( )  , 
rcvBeacon— >getEtx  ( )  , 
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my  _pstld )  ; 

else 

routingTableUpdateEntry  ( 

from  ,  rcvBeacon— >getParent  ( )  , 
rcvBeacon— >getEtx  ( )  , 
rcvBeacon— >get  Pst  Id  ()  )  ; 

command_CtpInfo_setNeighborCongested  (from  ,  congested  ) 

} 

i  f  (  command_CtpRoutingPacket_getOption  (msg  ,  CTP_OPTJPULL)  ) 
r eset  I  nt er val ()  ; 

delete  msg  ; 


Table  Update  Handler 

When  (A  table  update  event  is  received) 

Then 

1  Read  new  neighbor  information:  ID,  Parent  ID,  ETX,  PST  ID 

2  If  routing  table  is  full,  then  stop 

3  If  neighbor  PS  TDD  is  not  equal  to  my  PST_ID,  I  am  a  bridge 

4  Add  new  neighbor  information  to  the  routing  table 

Source  code: 

error.t  CtpRoutingEngine  :  :  routingTableUpdateEntry  ( 
am_addr_t  from  , 
am_addr_t  parent  , 
uint 1 6 _t  etx  , 
am_addr_t  pstld){ 

uint 8 _t  idx  ; 
uintl6_t  linkEtx  ; 

linkEtx  =  evaluateEtx  ( le  — >command_LinkEstimator_get LinkQuality  ( from )  )  ; 

idx  =  routingTableFind  (  from )  ; 
if(idx  =  rout  ingTableSize  )  { 

trace  ( )«”  routingTableUpdateEntry  ^FAIL  , ^table^full”  ; 
return  FAIL; 

} 

else  if(idx  =  rout  ingTable  Act  ive  )  { 

if  (passLinkEtxThreshold(linkEtx)  ){ 

rout  ingTable  [  idx  ].  neighbor  =  from; 
routingTable  [  idx  ]  .  pstld  =  pstld  ; 
rout  ingTable  [  idx  ].  info  .  parent  =  parent; 
rout  ingTable  [  idx  ].  info  .  etx  =  etx; 
rout  ingTable  [  idx  ].  info  .  haveHeard  =  1; 
rout  ingTable  [  idx  ].  info  .  congested  =  false; 
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rout  ingT  able  Act  ive++; 

trace  ()«”  routingTableUpdateEntry ..— ..OK,  unewu  entry”  ; 
if  (pstld  !=  my_pstld) 

trace  ()<<”##..  my  _pst  Id  :  T’«(int )  my_pstld«”  ^neighbor  ..pstld  :  ..” 
«pstld  ; 

} 

else 

trace  ()«”  routingTableUpdateEntry  ..—  ..F ail  ,^link  ^quality  (” 

«(int )  linkEtx«”  )  ..below  ..threshold”  ; 


} 

else  { 

//found,  just  update 
rout  ingTable  [  idx  ].  neighbor  =  from; 
routingTable  [  idx  ].  info  .  parent  =  parent; 
rout  ingTable  [  idx  ].  i  n  fo  .  etx  =  etx  ; 
routingTable  [  idx  ].  info  .  haveHeard  =  1; 

trace  ()«”  routingTableUpdateEntry  ..—..OK,  ..updated ..entry”  ; 

} 

return  SUCCESS; 

} 

Update  Route  Handler: 

When  (An  update  route  event  is  received) 

Then 

1  Read  all  neighbor  information  from  the  table:  ID,  Parent  ID,  ETX,  PSTJD 

2  Pick  the  neighbor  with  the  best  ETX 

3  Set  that  neighbor  as  the  new  parent 

Source  code: 

void  CtpRoutingEngine  :  :  updateRouteTask  ()  { 
uint8_t  i ; 

routing_table_entry *  entry; 
routing_t able.entry *  best; 
uintl6_t  minEtx ; 
uintl6_t  currentEtx; 
uintl6_t  linkEtx  ,  pathEtx ; 

if  ( state_is_root  ) 

return ; 

best  =  NULL ; 

/*  Minimum  etx  found  among  neighbors  ,  initially  infinity  */ 
minEtx  =  MAXJVfETRIC; 

/*  Metric  through  current  parent,  initially  infinity  */ 
currentEtx  =  MAXJVfETRIC ; 


trace  ()«”  updateRouteTask”  ; 


30 


/*  Find  best  path  in  table  ,  other  than  our  current  */ 
for(i  =  0;  i  <  routingTableActive;  i++){ 
entry  =  &rout ingTable  [  i  ]  ; 

//  Avoid  bad  entries  and  1—hop  loops 
i  f  (  entry  — >info  .  parent  =  INVALID ^VDDR  || 
entry— >info  .  parent  =  my_ll_addr){ 

trace  ()«”  routingTable  [”«(int )  i«”  ]  :  ^neighbor  :  [  id  :  V’ 

«(int )  entry— >neighbor«”  ^parent  :  V’«entry  — >info  .  parent 
«”  ^etx  :  ^NO-ROUTE]  ”  ; 

continue  ; 

} 

//  Compute  this  neighb  or  ’s  path  metric 

linkEtx  =  evaluateEtx  ( le  — >command_LinkEstimator .getLinkQuality  (  entry  — >neighbor  )  )  ; 

trace  ()«”  routingTable  [”<<(int )  i«”  ]  :  ^neighbor  :  ..[id  :  V’ <<(int )  entry  — >neighbor 
«”  ^parent  :  V’«entry  — >info  .  parent «”  ^etx  :  V’«(int )  linkEtx 
«”  ^pstld  :  V’«(int )  entry->pst Id «”  ]  ”  ; 

pathEtx  =  linkEtx  +  entry  — >info  .  etx  ; 

/*  Operations  specific  to  the  current  parent  */ 
i  f  (  entry  — >neighbor  =  rout  elnfo  .  parent )  { 
trace  ()«”  already  ^parent”  ; 

currentEtx  =  pathEtx; 

/*  update  routelnfo  with  parent’s  current  info  */ 

routelnfo . etx  =  entry — >info . etx ; 

routelnfo  .  congested  =  entry— >info  .  congested  ; 

continue  ; 

} 

/*  Ignore  links  that  are  congested  */ 
i  f  (  entry  — >info  .  congested) 

continue  ; 

/*  Ignore  links  that  are  bad  */ 
i  f  ( !  passLinkEtxThreshold  (linkEtx)){ 

trace  ()«”  did  ^not  ^pass^threshold  .  ”  ; 

continue  ; 

} 

if  (pathEtx  <  minEtx){ 
minEtx  =  pathEtx ; 
best  =  entry ; 

} 

} 

if  (minEtx  !=  MAXJV1ETRIC)  { 

if  (currentEtx  =  MAXJV1ETRIC  || 
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(  routelnfo  .  congested  &&  (minEtx  <  (  rout  elnfo  .  etx  +  10)))  | 

minEtx  +  PARENT_SWITCH_THRESHOLD  <  currentEtx){ 

parent  Changes++; 

trace  ()«”  Changed  ^parent  .  ^from^”«(int )  routelnfo  .  parent «”  ^to^” 
«(int )  best  — >neighbor «”  ^with^pstld  ^”«(int )  best— >pstld  ; 

le  — >command_LinkEstimator_unpinNeighbor  (  routelnfo  .  parent )  ; 

le  — >command_LinkEstimator_pinNeighbor  (best  — >neighbor  )  ; 

le  — >command_LinkEstimator_clearDLQ  (  best  — >neighbor  )  ; 

routelnfo  .  parent  =  best  — >neighbor  ; 
routelnfo  .  etx  =  best  — >info  .  etx  ; 
routelnfo  .  congested  =  best— >info  .  congested  ; 
my.pstld  =  best— >pstld  ; 

} 

} 

else  i f  (!  j ust Evicted  &&; 

currentEtx  =  MAXJV1ETRIC  && 
minEtx  !=  MAXJVfETRIC) 
signal_Rout ing.routeFound  ( )  ; 

justEvicted  =  false; 

} 


10  Simulations 

Our  research  has  utilized  simulations  in  order  to  increase  our  understanding  of  how  the  CTP 
works,  and  also  to  show  some  principles  of  the  network.  Our  network  simulations  utilize  the 
Castalia  v3.0  wireless  sensor  networks  simulator,  which  operates  on  top  of  the  OMNeT++ 
v4.1  network  simulator.  In  the  Castalia  simulator,  we  have  modified  an  implementation  of 
the  CTP  protocol  adapted  for  the  C++  language  used  by  Castalia.  The  original  C++  code 
for  the  CTP  protocol  has  been  provided  to  us  by  the  authors  of  [6]. 

In  our  project,  we  simulated  networks  of  50,  150,  and  300  MICA2  WSN  nodes  with  a  single 
base  station.  The  simulated  WSN  networks  were  programmed  to  use  the  CTP  protocol 
for  routing.  After  successfully  simulating  a  network  of  50  nodes,  we  moved  on  to  simulating 
larger  networks.  In  addition,  we  implemented  a  sinkhole  node  in  the  simulation  network.  The 
sinkhole  actively  sends  and  receives  network  beacons  but  does  not  forward  actual  application 
(sensor)  data  to  the  base  station. 
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Data  from  sixty  simulation  runs  are  shown  in  Appendix  A.l.  The  graph  shows  the  effect  a 
sinkhole  can  have  on  a  WSN  that  utilizes  CTP.  The  graph  shows  simulations  on  a  300  node 
network.  In  these  simulation  runs,  thirty  individual  network  topologies  were  used.  Each 
topology  was  generated  using  a  random  uniform  distribution.  Within  each  distribution,  two 
simulations  were  run:  one  that  tested  the  network  with  a  sinkhole,  and  one  that  tested  the 
network  without  a  sinkhole.  The  graph  shows  the  individual  topologies  as  two  columns:  the 
red  column  represents  packet  loss7  (as  a  percentage)  with  a  sinkhole,  while  the  blue  column 
represents  the  packet  loss  without  a  sinkhole.  It  is  important  to  note  that  there  can  be  packet 
loss  when  there  is  no  sinkhole  in  the  network  -  these  losses  can  be  attributed  to  simulated 
data  collisions8  or  errors. 

Simulations  were  also  conducted  using  our  modified  protocol.  Through  the  trace  hie  gener¬ 
ated  during  each  simulation  run,  we  were  able  to  determine  that  bridge  nodes  were  success¬ 
fully  discovered  by  our  protocol. 


11  Conclusion 

This  project  has  developed  a  novel  strategy  to  mitigate  sinkhole  attacks  in  WSNs  that  utilize 
tree  structured  routing.  Our  work  has  shown  that  an  implementation  of  this  strategy  in  the 
CTP  protocol  is  feasible  based  on  simulations  that  show  the  existence  of  ‘bridge  nodes’ 
in  ad-hoc  WSNs  that  are  initialized  using  CTP.  Future  work  on  this  area  might  include 
implementing  our  sinkhole  mitigation  strategy  into  a  working  version  of  the  Collection  Tree 
Protocol  (CTP)  and  testing  its  effectiveness  with  respect  to  the  overall  data  delivery  ratio 
in  the  Castalia  wireless  sensor  networks  simulator. 
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A  Appendix 

A.l  Effect  of  Sinkhole  in  Simulation 

Note:  This  graph  is  described  in  the  Simulations  section 


A. 2  Source  Code 


CTP  Routing  Engine: 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 


^include  ”  CtpRoutingEngine  .  h” 
ffi nclude  ”  CtpForwardingEngine  .  h” 

^include  ”  LinkEstimator  .  h” 

Define_Module  (CtpRoutingEngine)  ; 

void  CtpRoutingEngine::  initialize  (){ 

////////////////////////  C  astalia  Implementation  //////////////////// 

///////////////////////////////////////////////////////////////////// 

//Pointers  to  other  modules  for  direct  function  calls  . 

cfe  =  check_and_cast<CtpForwardingEngine*>(getParentModule(  )— >get Submodule  (”  CtpForwardingEngine”  )  ) 
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13 

14 

15 

16 

17 
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29 
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31 

32 

33 

34 

35 

36 

37 

38 
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40 

41 
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43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 


le  =  check.and.cast  <LinkEstimat  or  *>  (get  Parent  Module  (  )—>get  Sub  module  (”  LinkEstimator  ”)  )  ; 

//Id  of  the  node  (like  TOS-NODE.ID) 

self  =  getParentModule  ()  — > getParentModule  ()  — > getParentModule  ()  — > getlndex  ()  ; 

//  The  default  values  are  set  in  CtpRoutingEngine  .  ned 
//  but  they  can  be  overwritten  in  omnetpp  .  ini 

routingTableSize  =  par(”routingTableSize”)  ;  //  default  10  entries 

minlnterval  =  par  (”  minlnterval”  )  ;  //  default  128 

maxlnterval  =  par  (”  maxlnterval”  )  ;  //  default  512000 

ctpReHeaderSize  =  par  (”  ctpReHeaderSize”  )  ;  //  default  header  size  :  5  bytes 

isRoot  =  par  (”  isRoot”  )  ;  //  sets  this  node  as  root 

//  Clock  drift  simulation  ( it  is  present  at  each  layer) 

if  (  getParentModule  (  )—>get  Parent  Module  (  )—>get  Parent  Module  (  )—>find  Submodule  (’’ResourceManager”  )  !  = 

-i)  { 

resMgrModule  =  check.and.cast  <ResourceManager  *>(getParentModule  (  )—  >getParentModule  (  )—  > 
getParentModule  (  )— >get  Submodule  (’’ResourceManager”  )  )  ; 

}  else  { 

opp.error  (”\n  [ Mac ]  :  \  n_Error_ in-geting-a_ valid  -  reference  -  to_ResourceManager_for  -  direct  _ 
method  -  calls  .”)  ; 

} 

setTimer  Drift  (  resMgrModule— >getCPUClockDrift  ()  )  ; 

///////////////////////////////////////////////////////////////////// 

///////////////////////////////////////////////////////////////////// 

/////////////////////  CtpForwardingEngine  (default)  ///////////////// 

///////////////////////////////////////////////////////////////////// 

ECNOff  =  true  ; 

radioOn  =  true  ;  //  TO  IMPLEMENT - radio  On  in  s  t  d  c  o  ntr  o  l 

running  =  false  ; 
sending  =  false  ; 
justEvicted  =  false  ; 

routingTable  =  new  routing.table.entry  [routingTableSize]  ; 
c u r r e n 1 1 n t e r v  al  =  minlnterval; 


///////////////////////////////////////////////////////////////////// 

///////////////////////////////////////////////////////////////////// 

///////////////////////////  Init.initO  ///////////////////////////// 

///////////////////////////////////////////////////////////////////// 

routeUpdateTimer  Count  =  0; 
parentChanges  =  0; 
s  t  a  t  e  _  i  s  _  r  o  o  t  =  0; 

routelnfolnit(&routelnfo) ; 
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61 

62 

63 

64 

65 


routingTablelnit  ()  ; 

my.ll.addr  =  command.AMPacket.address  ( )  ; 

beaconMsg  =  new  CtpBeacon  ()  ; 

beacon  Msg—  >setByteLength  (  ctpReHeaderSize  ) 
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//  Call  the  corresp  onding  rootcontrol  command 

isRoot?  command.RootControLsetRoot  ()  :  command_RootControl_unsetRoot  ( ) 

///////////////////////////////////////////////////////////////////// 

///////////////////////////////////////////////////////////////////// 


////////////////////////////////  Statistics  ///////////////////////////////// 

///////////////////////////////////////////////////////////////////////////// 

declareOutput  (  ”  Ctp_Beacons”  )  ; 

///////////////////////////////////////////////////////////////////////////// 

///////////////////////////////////////////////////////////////////////////// 


void  CtpRoutingEngine  :  :  handleMessage  (cMessage*  msg)  { 
int  msgKind  =  msg— >getKind  (  )  ; 

switch  (msgKind)  { 
case  TIMER_SERVICE :  { 

handleTimer Message  (msg)  ; 
break ; 

} 

default  :  { 

opp.error  (”U nko wn „message„type  .  ”  )  ; 

} 

} 

delete  msg  ; 

} 

void  Ct  pRoutingEngine  :  :  t  i  mer  F  i  r  e  d  C  all  b  ac  k  (  i  n  t  timer) 

{ 

trace  ()  «  ”  CtpRE_— -TimerFiredCallback  , -value  :  _”«timer  ; 
switch  (timer)  { 

case  ROUTE_TIMER:  { 

setTimer  (ROUTE_TIMER,  tosMillisToSeconds  ( BEACON JNTERVAL)  )  ;  //  because  it  ’s  a 

periodic  timer. 
event  .RouteTimer  _fired  (  )  ; 

break ; 

} 

case  BEACON.TIMER:  { 

event.BeaconTimer.fired  ()  ; 

break ; 

} 

case  POST JJPDATEROUTETASK :  { 
updateRouteTask  ()  ; 

break 

} 

case  POST_SENDBEACONTASK :  { 
sendBeaconTask  ()  ; 

break 

} 


} 


} 


default  :  { 

opp.error  (’’Unexpected-message  !”  )  ; 


} 


CtpRoutingEngine  :  :  ~  CtpRoutingEngine  ()  { 
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159 

160 
161 
162 

163 

164 

165 

166 
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168 

169 
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171 
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173 

174 
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176 

177 

178 
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delete  beaconMsg  ; 
beaconMsg  =  NULL  ; 

delete  []  routingTable 
routingTable  =  NULL  ; 


void  CtpRoutingEngine  :  :  chooseAdvertiseTime  (  )  { 

t  =  cur r ent I nter val ; 
t  /=  2; 

t  +=  command_Random_rand32  (  1 )  %  t; 
tHasPassed  =  false; 

setTimer  (  BEACON_TIMER,  tosMillisToSeconds(t))  ; 

} 

void  CtpRoutingEngine  :  :  r  e  s  e  1 1  n  t  e  r  v  a  1  ()  { 

c u r r e n 1 1 n t e r v  a  1  =  minlnterval; 
chooseAdvertiseTime  ()  ; 

} 

void  CtpRoutingEngine  :  :  decay  Interval  ()  { 

c u r r e n 1 1 n t e r v  al  *=  2; 

if  (  c  u  r  r  e  n  1 1  n  t  e  r  v  al  >  maxlnterval)  { 

c  u  r  r  e  n  1 1  n  t  e  r  v  a  1  =  maxlnterval; 

} 

chooseAdvertiseTime  (  )  ; 

} 

void  CtpRoutingEngine  :  :  remaininglnterval  ()  { 

uint32_t  remaining  =  c  u  r  r  e  n  1 1  n  t  e  r  v  a  1  ; 
remaining  — =  t  ; 
tHasPassed  =  true  ; 

setTimer  ( BEACON_TIMER ,  tosMillisToSeconds  (remaining)  )  ; 

} 

error.t  CtpRoutingEngine  :  :  command.StdControl.start  ()  { 

Enter  .Method  (  ”  command.StdControl.start”  )  ; 

//start  will  (re)start  the  sending  of  messages 
if  (  !  running)  { 

running  =  true  ; 
resetlnterval () ; 

setTimer  ( ROUTE.TIMER ,  tosMillisToSeconds  ( BEACON JNTERVAL )  )  ; 

trace  (  )«”  stdControl  .  start  running  ^”<<r  unning  <<”  ^radioOn  :  _”«radioO 

} 

return  SUCCESS; 

} 

error.t  CtpRoutingEngine  ::  command.StdControl.stop  (  )  { 

Enter  .Met  hod  (’’command.StdControl.stop”)  ; 
running  =  false  ; 

trace  (  )«”  stdControl  .  stop  ^-.running  _”«r  unning  «”  _  radio  On  :  _”«radioOn  ; 
return  SUCCESS; 

} 

void  CtpRoutingEngine  :  :  event.RadioControl.startDone  (  error.t  error)  { 

Enter  .Met  hod  (”  event.RadioControl.startDone”  )  ; 

radioOn  =  true  ; 

trace  (  )«”  radioControl  .  startDone  ^running  ^”«running«”  ..radioOn  :  u”«  radioOn 
if  (running)  { 

uintl6_t  nextlnt; 

nextlnt  =  command_Random_randl6  ( 0 )  %  BEACONJNTERVAL  ; 
nextlnt  +=  BEACONJNTERVAL  »  1; 

setTimer  (BEACON.TIMER,  tosMillisToSeconds  (  nextlnt  )  )  ; 

} 

} 

void  CtpRoutingEngine  ::event_RadioControl_stopDone(error_t  error)  { 

Enter  .Met  hod  (”  event.RadioControl.stopDone”  )  ; 

radioOn  =  false  ; 

trace  ()«”  radioControl  .  stopDone.-  .running  _”«running«”  .radioOn  :  .”«radioOn  ; 
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200 

201  } 

202 

203  /*  Is  this  quality  measure  better  than  the  minimum  threshold?  */ 

204  //  Implemented  assuming  quality  is  EETX 

205  bool  Ct  pRoutingEngine  :  :  passL  inkEtxThr  eshold  (  u  i  n  1 1  6  _t  etx)  { 

206  return  true  ; 

207  //  return  ( etx  <  ETX-THRESHOLD )  ; 

208  } 

209 

210  /*  Converts  the  output  of  the  link  estimator  to  path  metric 

211  *  units  ,  that  can  be  *  added*  to  form  path  metric  measures  */ 

212  uintl6_t  CtpRoutingEngine  :  :  evaluateEtx  (  uint  1  6  _t  quality)  { 

213  trace  (  )«”  evaluateEtx  <<(int)  quality  «”  >„”  <<(int)  (quality+10)  ; 

214  return  (quality  +  10); 

215  } 

216 

217 

218  /*  up  dates  the  routing  information  ,  using  the  info  that  has  been  received 

219  *  from  neighbor  beacons.  Two  things  can  cause  this  info  to  change: 

220  *  neighbor  beacons  ,  changes  in  link  estimates  ,  including  neighbor  eviction  */ 

221  void  CtpRoutingEngine  :  :  updateRouteTask  ()  { 

222  uint  8  _t  i  ; 

223  r  o  u  t  i  n  g  _  t  a  b  1  e  _e  n  t  r  y  *  entry; 

224  r  o  u  t  i  n  g  _  t  a  b  1  e  _e  n  t  r  y  *  best; 

225  uintl6_t  minEtx ; 

226  uintl6_t  currentEtx  ; 

227  uintl6_t  linkEtx  ,  pathEtx  ; 

228 

229  if  (  state.is.root  ) 

230  return  ; 

best  =  NULL; 

/*  Minimum  etx  found  among  neighbors  ,  initially  infinity  */ 
minEtx  =  MAX_METRIC ; 

/*  Metric  through  current  parent  ,  initially  infinity  */ 
currentEtx  =  MAX_METRIC ; 

237  I 

238  trace  ()«”  updateRouteTask”  ; 

best  path  in  table  ,  other  than  our  current  */ 

0;  i  <  routingTableActive;  i++)  { 
entry  =  feroutingTable  [  i  ]  ; 

//  Avoid  bad  entries  and  1—hop  loops 

if  (entry->info  .  parent  ==  INVALID_ADDR  ||  entry->info  .  parent  ==  my.ll.addr )  { 

trace  (  )«”  routingTable  [”<<(int  )  i  «”  ]  :  ..neighbor  :  ..[id  :  ..”<<(int)  ent  r  y  — >neighbor  «”  _ 
parent  :  „”«ent r y  — >i n f  o  .  parent  «”  „„etx  :  JMO J-tOUTE]  ”  ; 

continue  ; 

} 

/*  Compute  this  neighbor  ’s  path  metric  */ 

linkEtx  =:  evaluateEtx  (/*  c  a  1 1  Link  E  stimat  or  .  g  et  L  ink  Q  u  ality  (  entry  — >  n  ei  g  hb  or  )  changed  with: 

*/  le  —  >command_LinkEstimator _getLinkQuality  (  entry  — >neighbor  )  )  ; 
trace  (  )«”  routingTable  [”<<(int)i  «”  ]  :  ^neighbor  :  _  [  id  :  _”<<(int  )  entry  — >neighbor  «”  ..parent  : 

«ent  ry  — >  info  .  parent  «” _ etx  :  _”<<(int  )  linkEtx 

«”  _  p  s  1 1  d  :  _”<<(int  )  entry  — >noneps t Id  «”  ]  ”  ; 
pathEtx  =:  linkEtx  +  entry->info  .  etx  ; 

/*  Op  erations  specific  to  the  current  parent  */ 
if  (entry  — >  neighbor  ==  routelnfo  .  parent)  { 
trace  ()«”  already  ^parent”  ; 
currentEtx  =  pathEtx; 

/*  update  routelnfo  with  parent  ’s  current  info  */ 
routelnfo. etx  =  entry  — > info  . etx ; 
routelnfo.  congested  =  entry  — > info  .  congested  ; 

continue  ; 

} 

/*  Ignore  links  that  are  congested  */ 
if  (entry  — > info  .  congested) 

continue  ; 

/*  Ignore  links  that  are  bad  */ 


/*  Find 

for  (  i  = 
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265 

266 
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267 

if  (  !  passLinkEtxThr eshold  (  linkEtx  )  )  { 

268 

trace  (  ) «”  did_not_pass_threshold  .  ”  ; 

269 

continue  ; 

270 

} 

271 

272 

if  (pathEtx  <  minEtx)  { 

273 

minEtx  =  pathEtx  ; 

274 

best  =  entry  ; 

275 

} 

276 

} 

277 

278 

279 

/*  Now  choose  between  the  current  parent  and  the  best  neighbor  */ 

280 

/*  Requires  that  : 

281 

1.  at  least  another  neighbor  was  found  with  ok  quality  and  not  congested 

282 

2.  the  current  parent  is  congested  and  the  other  best  route  is  at  least  as  good 

283 

3.  or  the  current  parent  is  not  congested  and  the  neighb  or  quality  is  better  by 

284 

t  h  e  PA  RENT_S  WITCH.  THRESHOLD . 

285 

Note:  if  our  parent  is  congested  ,  in  order  to  avoid  forming  loops  ,  we  try  to  select 

286 

a  node  which  is  not  a  des c  en  dent  of  our  parent .  r  o  ut  e I nf  o  .  ext  is  our  parent  ’ s 

287 

etx .  Any  descendent  will  be  at  least  that  +  10  (1  hop) ,  so  we  restrict  the 

288 

selection  to  be  less  than  that. 

289 

*/ 

290 

if  (minEtx  !=  MAXA1ETRIC)  { 

291 

if  (currentEtx  =  MAX  METRIC  |  | 

292 

(routelnfo  .  congested  &&;  ( minEtx  <  (routelnfo.etx  +  10)))  | 

293 

minEtx  +  PARENT J3WITCH_THRESHOLD  <  currentEtx)  { 

294 

//  r  o  ut  e  In  f  o  .  metric  will  not  store  the  composed  metric  . 

295 

//  since  the  linkMetric  may  change  ,  we  will  compose  whenever 

296 

//  we  need  it:  i.  when  choosing  a  parent  (here); 

297 

//  ii  .  when  cho  o  sing  a  next  hop 

298 

parentChangesH — |-; 

299 

300 

trace  (  )«”  Changed  ^parent  .  _from_”«(int  )  routelnfo  .  parent  «”  _to_”<<(int  )  best  — > 

neighbor  «”  _with_pstld_”<<(int  )  best  — >none  ps  1 1  d  ; 

301 

le  — >command_LinkEst  i  mat  or  .unpinNeighbor  (routelnfo  .  parent)  ; 

302 

le  — >command_LinkEstimator_pinNeighbor  (best  —  >neighbor  )  ; 

303 

le  — >comm and -Link Estimator _clearDLQ  (best  — >neighbor  )  ; 

304 

305 

routelnfo.  parent  =  best  — >  neighbor  ; 

306 

routelnfo.etx  =  best  — > info  .  etx ; 

307 

routelnfo.  congested  =  best  — > info  .  congested  ; 

308 

nonemy_pstId  =  best  — >nonepstId  ; 

309 

} 

310 

} 

311 

312 

/*  Finally  ,  tell  people  what  happened  :  */ 

313 

/ *  We  can  only  loose  a  route  to  a  parent  if  it  has  been  evicted.  If  it  hasn’t 

314 

*  been  just  evicted  then  we  already  did  not  have  a  route  */ 

315 

if  (justEvicted  &&  routelnfo.  parent  ==  INVALID-ADDR) 

316 

signal.Routing.noRoute  ()  ; 

317 

/*  On  the  other  hand,  if  we  didn  ’t  have  a  parent  (no  currentEtx)  and  now  we 

318 

*  do,  then  we  signal  route  found.  The  exception  is  if  we  just  evicted  the 

319 

*  parent  and  immediately  found  a  replacement  route:  we  don’t  signal  in  this 

320 

*  case  */ 

321 

else  if  (  !  j  ustE  victed  8z8z 

322 

currentEtx  ==  MAX-METRIC  && 

323 

minEtx  !=  MAX -METRIC ) 

324 

signal_Routing_routeFound  (  )  ; 

325 

justEvicted  =  false  ; 

326 

} 

327 

328 

/*  send  a  beacon  advertising  this  node  ’s  routelnfo  */ 

329 

//  only  posted  if  running  and  radioOn 

330 

void  CtpRoutingEngine  :  :  sendBeaconTask  (  )  { 

331 

error _t  eval  ; 

332 

if  (sending)  { 

333 

return ; 

334 

} 

335 
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360 

361 

362 

363 

364 
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375 

376 
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381 
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beaconMsg— >s et  O  p t  io ns  (  0  )  ; 

/*  Congestion  notification:  am  I  congested?  *  / 
if  (  cfe  — >command_CtpCongestion_isCongested  (  )  )  { 

beaconMsg— >set  O  pt  ions  (  beaconMsg—  >get  O  pt  ions  (  )  |  CTP_OPT_ECN)  ; 

} 

beaconMsg— >s et P arent  (routelnfo  .  parent)  ; 
if  (  s  t  a  t  e  _  i  s  _  r  o  o  t  )  { 

beaconMsg— >se  t  Et  x  (routelnfo  .  etx)  ; 

} 

else  if  (routelnfo.  parent  =  INVALID_ADDR)  { 
beaconMsg— >set Etx  (routelnfo  .  etx)  ; 

beaconMsg— >set  O  pt  ions  (  beaconMsg— >get  O  pt  ions  (  )  |  CTP_OPT_PULL )  ; 

}  else  { 

beaconMsg— >set  Etx  (routelnfo.  etx  +  le  — >command  _LinkEst  imat  or  _get  LinkQ  ualit  y  (routelnfo  . 
parent ) )  ; 

} 


beaconMsg—  >noneset  Pstld  (nonemy _pstld  )  ;  //  hmm; 


should  have  set  my_pstld  to  that  of  my  parent 


} 

void 


} 

void 


} 

void 


trace  (  )«”  send BeaconT ask _—  _ par ent  :  _”<<(int  )  beaconMsg— >get  P arent  (  )«”  _  etx  :  _”<<(int  )  beaconMsg— > 
getEtx  (  )  ; 

beaconMsg— >get  Ro  ut  i  ng  I  nt  e  r  act  i  o  n  C  o  nt  r  o  1  (  )  .  lastHop  =  self  ;  //  ok 

eval  =  le  —  >command_Send_send  ( AM_BROADCAST_AJDDR,  beaconMsg— >dup  ())  ;  //  the  duplicate  will  be  deleted 

in  the  LE  module  ,  we  keep  a  copy  here  that  is  reused  each  time. 

if  (eval  ==  SUCCESS)  { 

//  statistics 

c o  1  le c  t  O  ut  p  ut  (”  Ctp Beacons  ”  ,  ”  Tx”  )  ; 

sending  =  true ; 

}  else  if  (eval  ==  EOFF )  { 
radioOn  =  false  ; 

trace  (  )«”  sendBeaconT ask _ r unni ng  :  _”«r unning «”  _ radioOn  :  _"«radioOn  ; 

} 

CtpRoutingEngine  :  :  event.BeaconSend.sendDone  (cMessage*  msg  ,  error.t  error)  { 

Enter.Method  (”  event.BeaconSend.sendDone”  )  ; 

if  (  !  sending )  { 

//something  smells  bad  around  here 

opp.error  (”  something^smells  ^bad^around  ^here”  )  ; 

return  ; 

} 

sending  =  false ; 


CtpRoutingEngine  :  :  event  _RouteTimer_fired  ()  { 

if  (radioOn  running)  { 

post  .updateRouteTask  (  )  ; 

} 


CtpRoutingEngine  :  :  event.BeaconTimer.fired  ()  { 

if  (radioOn  &&;  running)  { 
if  (  !  tHasPassed  )  { 

post.updateRouteTask  ()  ;  //  always  the  most  up  to  date  info 

post.sendBeaconTask  (  )  ; 

trace  (  )«”  Beacon ^ t  imer  ^  f  i  r  e  d  .  ”  ; 

remaininglnter  val  (  )  ; 

} 

else  { 

d ec ay I n t e r v al ( ) ; 

} 

} 


A 

*  We  don  ’t  need  a  pointer  to  the  header ,  we  can  use  the  methods  of  cPacket 
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*  instead  ,  we  return  a  pointer  to  Ctp B eacon  and  that  ’s  it  . 

*/ 

CtpBeacon*  CtpRoutingEngine  :  :  getHeader  (  cPacket  *  msg)  { 
return  check.and.cast  <CtpBeacon * > (msg )  ; 

} 

/*  Handle  the  receiving  of  beacon  messages  from  the  neighbors.  We  update  the 

*  table  ,  but  wait  for  the  next  route  update  to  choose  a  new  parent  */ 
void  CtpRoutingEngine  :  :  event.BeaconReceive.receive  (cPacket*  msg)  { 

Enter -Method  (”  event_BeaconReceive_receive”  )  ; 

am_addr_t  from  ; 
bool  congested  ; 

//  statistics 

c  o  1 1  e  ct  O  ut  p  ut  (”  Ctp  _ Beacons  ”  ,  ”  Rx”  )  ; 

//  we  skip  the  check  of  beacon  length. 

//need  to  get  the  am_addr_t  of  the  source 
from  =  command_AMPacket_source  (msg)  ; 

CtpBeacon*  rcvBeacon  =  check.and.cast  <CtpBeacon* > (msg )  ; 

congested  =  command.CtpRoutingPacket  .get  Option  (  msg  ,  CTP_OPT_ECN)  ; 

trace  (  )«”  BeaconReceive  .  receive  -from  <<(  in  t  )  from«”  ^  [  parent  :  ^”«(int  )  rc  vB  eacon  — >get  P  ar  ent  (  )«”  - 
etx  :  ^”<<(int  )  rcvBeacon— >getEtx  (  ) 

«”  ^pstld  :  ^”«(int  )  rc  v  Beacon  —  >nonege  t  P  s  1 1  d  (  )«”  ]  ”  ; 

//update  neighbor  table 

if  (  rcvBeacon— >get  P  ar  ent  (  )  !=  INVALID-ADDR)  { 

/*  If  this  node  is  a  root  ,  request  a  forced  insert  in  the  link 
*  estimator  table  and  pin  the  node.  */ 
if  (  rcvBeacon— >getEtx  ( )  ==  0)  { 

trace  (  )«”  from_a_root  ,  _inserting_if_not_in_table  my.ll.addr  :  _”«  my  .11  _ad  d  r  ; 

le  — >command_LinkEs  t  i  mat  or  .insert  N  eighbor(from)  ; 
le  — >command_LinkEstimator_pinNeighbor  (  from  )  ; 

nonemy.pstld  =  my.ll.addr  ;  //  since  i  hear  root  ,  i  ’m  the  root  of  a  principle 

subtree 

} 

/ /TODO :  also  ,  if  better  than  my  current  parent  ’s  path  etx  ,  insert 
if  (  rcvBeacon— >getEtx  (  )  ==  0) 

routingTableUpdateEntry  (  from  ,  rcvBeacon— >getParent  (  )  ,  rcvBeacon— >getEtx  (  )  , 
nonemy.pstld  )  ; 

else 

routingTableUpdateEntry  (from  ,  rcvBeacon  — >get  P  ar  ent  (  )  ,  rcvBeacon— >getEtx  (  )  , 
rcvBeacon— >noneget P st I d  ()  )  ; 

command.CtpInfo.setNeighborCongested  (from  ,  congested  )  ; 

} 

if  (  command.CtpRoutingPacket.getOption  (msg  ,  CTP_OPT_PULL)  )  { 
resetlnterval () ; 

} 

delete  msg  ; 

//  we  do  not  return  the  message  ,  we  delete  it. 

} 

/*  Signals  that  a  neighbor  is  no  longer  reachable,  need  special  care  if 

*  that  neighbor  is  our  parent  */ 

void  CtpRoutingEngine  :  :  event.LinkEstimator.evicted  (am.addr.t  neighbor)  { 

Enter _Met hod  (”  event_LinkEstimator_evicted”  )  ; 

routingTableEvict  (  neighbor)  ; 
trace  (  )  «”  LinkEstimator.  evicted”  ; 
if  (routelnfo  .  parent  ==  neighbor)  { 
routeInfoInit(&routeInfo) ; 
justEvicted  =  true; 
post  .updateRouteTask  (  )  ; 

} 

} 
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/* 

*  Unic  ast  N  ame  Fr  e  e  R  outing  Inteface - 

*/ 

/♦  Simple  implementation  :  return  the  current  routelnfo  ♦  / 
am.addr .t  CtpRoutingEngine  :  :  command.Routing.nextHop  ()  { 

Enter _Met hod  (’’command.Routing.nextHop”  )  ; 

return  routelnfo . parent ; 

} 

bool  CtpRoutingEngine  :  :  command.Routing.hasRoute  ()  { 

Enter _Met hod  ("command.Routing.hasRoute”  )  ; 

return  (  r  o  u  t  e I  n  f  o  .  p ar ent  !=  INVALID-ADDR)  ; 

} 

// - 

A 

*  Ctplnfo  Interface  (Part  1)  - 

*/ 

error.t  CtpRoutingEngine  :  :  command.CtpInfo_getParent(am.addr_t*  parent)  { 
if  (parent  =  NULL ) 
return  FAIL; 

if  (routelnfo.  parent  ==  INVALID-ADDR) 
return  FAIL; 

♦parent  =  routelnfo . parent ; 
return  SUCCESS; 

} 

error.t  CtpRoutingEngine  ::  command.CtpInfo.getEtx  (  u  i  nt  1  6  _t  *  etx)  { 

Enter.Method  (”  command.CtpInfo.getEtx”  )  ; 

if  (etx  ==  NULL) 

return  FAIL; 

if  (routelnfo.  parent  ==  INVALID-ADDR) 
return  FAIL; 

if  (  s  t  a  t  e  _  i  s  _  r  o  o  t  ;  -  1)  { 

♦  etx  =  0  ; 

}  else  { 

//  path  etx  =  etx(parent)  +  etx  ( link  to  the  parent) 

♦  etx  =  routelnfo.  etx  +  evaluateEtx  (  le  — >  command_LinkEstimator_getLinkQuality  (  routelnfo  . 

parent )  )  ; 

} 

return  SUCCESS; 

} 

void  CtpRoutingEngine  :  :  command.CtpInfo.recomputeRoutes  ()  { 

Enter.Method  (”  command.CtpInfo.recomputeRoutes”  )  ; 

post -updateRouteTask  (  )  ; 

} 

void  CtpRoutingEngine  ::  command-CtpInfo-triggerRouteUpdate  (  )  { 

Enter-Method  (  ”  command_CtpInfo_triggerRouteUpdate”  )  ; 

resetlnterval () ; 

} 

void  CtpRoutingEngine  :  :  command-CtpInfo.triggerlmmediateRouteUpdate  ()  { 

Enter -Met hod  (  ”  command-CtpInfo.triggerlmmediateRouteUpdate”  )  ; 

resetlnterval () ; 

} 

void  CtpRoutingEngine  :  :  command.CtpInfo.setNeighborCongested  (  am.addr.t  n,  bool  congested)  { 

Enter _Met hod  (”  command_CtpInfo_setNeighborCongested”  )  ; 

uint  8  _t  idx  ; 
if  (  ECNOff ) 

return  ; 

idx  =  r o u t ingTab leF i nd  ( n )  ; 
if  (idx  <  routingTable  Active )  { 

routingTable  [  idx].  info,  congested  =  congested; 

} 

if  ( r o u t e I n f o . con ges t ed  &&  ! congested ) 
post -updateRouteTask  (  )  ; 

else  if  (routelnfo  .  parent  =  n  &&  congested) 
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} 


post .updateRouteTask  () 


bool  CtpRoutingEngine  :  :  command_CtpInfo_isNeighborCongested  (  am.addr.t  n)  { 
Enter _Met hod  (  ”  command.CtpInfo.isNeighborCongested”  )  ; 

uint  8  _t  idx  ; 

if  (  ECNOff ) 

return  false ; 


idx  =  routingTableFind  (n)  ; 
if  (idx  <  routingTable  Active )  { 

return  routingTable  [idx  ]  .  info  .  congested  ; 

} 

return  false ; 

} 

// - 

A 

*  RootControl  Interface - 

*/ 

/**  sets  the  current  node  as  a  root  ,  if  not  already  a  root  */ 

/*  returns  FAIL  if  it  ’s  not  possible  for  some  reason  */ 

error.t  CtpRoutingEngine  :  :  command.RootControLsetRoot  ()  { 

Enter_Method  (”  command-RootControl.setRoot  ”  )  ; 

bool  route_found  =  false  ; 

route_found  =  (routelnfo.  parent  =  INVALID-ADDR)  ; 
s  t  a  t  e  _  i  s  _  r  o  o  t  =  1; 

nonemy_pstId  =  0;  //  a  root  is  no  principle  subtree 

r  o  u  t  e  I  n  f  o  .  par  ent  =  my.ll.addr  ;  //myself 
r  o  u  t  e  I  n  f  o  .  et  x  =  0; 
if  (route_found) 

signal-Routing.routeFound  (  )  ; 

trace  (  )«”  RootControl  .  setRoot  _ I  ’m_a_ r oo t  _now  !  ”<<(int  )  routelnfo  .  parent 
return  SUCCESS; 

} 

error.t  CtpRoutingEngine  :  :  command_RootControl_unsetRoot  ()  { 

Enter.Method  (”  command_RootControl_unsetRoot”  )  ; 

s  t  a  t  e  _  i  s  _  r  o  o  t  =  0; 
r  o  u  t  e  I  n  f  o  I  n  i  t  (&;  r  o  u  t  e  I  n  f  o  )  ; 

trace  (  )«”  RootControl  .  unsetRoot  ^ I  ’m^not  ^a„root  „now  !  ”  ; 

post  .updateRouteTask  (  )  ; 

return  SUCCESS; 


bool  CtpRoutingEngine  ::  command-RootControl-isRoot  (  )  { 

Enter.Method  (”  command-RootControl.isRoot”  )  ; 

return  state.is.root  ; 

} 

// - 

//  default  events  Routing  .  noRoute  and  Routing  .  routeF ound  skipped  —  >  useless 

/*  This  should  see  if  the  node  should  be  inserted  in  the  table  . 

*  If  the  w  hit  e -b it  is  set  ,  this  means  the  LL  believes  this  is  a  good 

*  first  hop  link. 

*  The  link  will  be  recommended  for  insertion  if  it  is  better*  than  some 

*  link  in  the  routing  table  that  is  not  our  parent. 

*  We  are  comparing  the  path  quality  up  to  the  node,  and  ignoring  the  link 

*  quality  from  us  to  the  node.  This  is  because  of  a  couple  of  things: 


* 

1 . 

because  of  the  white  bit  ,  we 

assume  that 

the  1—hop 

t  o 

the  candidat 

* 

link 

is  good  (say  ,  etx=l) 

* 

2. 

we  are  being  optimistic  to  the  nodes  in 

the  table  , 

by 

ignoring  the 

* 

1—hop 

quality  to  them  (which 

means  we  are  assuming 

i  t 

’  s  1  as  well) 

* 

This 

actually  sets  the  bar  a 

little  high 

er  for  replacement 

* 

3. 

this 

is  faster 

* 

4- 

it  do 

esn  ’t  require  the  link 

estimator  to 

have  stab : 

Hi  z  e  d  on  a  link 

*  / 

bool  CtpRoutingEngine  :  :  event.CompareBit.shouldlnsert  (cPacket  *msg  ,  bool  white.bit)  { 
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608 

Enter  .Method  (  ”  event.CompareBit.shouldlnsert”  )  ; 

609 

bool  found  =  false  ; 

610 

uintl6_t  pathEtx  ; 

611 

uintl6_t  neighEtx  ; 

612 

i nt  i  ; 

613 

routing.table.entry*  entry; 

614 

CtpBeacon*  rcvBeacon  ; 

615 

616 

//  checks  if  it  is  a  CtpBeacon 

617 

if  (dynamic_cast<CtpBeacon*>(msg)  =  NULL)  { 

618 

delete  msg  ; 

619 

return  false  ; 

620 

} 

621 

622 

/*  1.  determine  this  packet  ’s  path  quality  */ 

623 

rcvBeacon  =  check.and.cast  <CtpBeacon*>(msg)  ;  //  we  don  ’t  need  a  pointer  to  header  ,  we  use  cPacket 

metho ds  . 

624 

625 

if  (  rcvBeacon— >getParent  (  )  ==  INVALID_ADDR)  { 

626 

delete  msg  ; 

627 

return  false ; 

628 

} 

629 

630 

/*  the  node  is  a  root,  recommend  insertion!  */ 

631 

if  (  rcvBeacon—  >getEtx  ( )  ==  0)  { 

632 

delete  msg  ; 

633 

return  true  ; 

634 

} 

635 

636 

pathEtx  =  rcvBeacon— >getEtx  (  )  ; 

637 

638 

/*  2.  see  if  we  find  some  neighbor  that  is  worse  */ 

639 

for  (i  =  0;  i  <  routingTable  Active  &&  !  found  ;  i++)  { 

640 

entry  =  ^routingTable  [  i  ]  ; 

641 

//ignore  parent ,  since  we  can  ’t  replace  it 

642 

if  (entry  — > neighbor  ==:  routelnfo  .  parent) 

643 

continue  ; 

644 

neighEtx  =  entry  — > info  .  e t x  ; 

645 

//neighEtx  =  evaluateEtx  (  c  all  LinkE  stimat  or  .  g  et  L  ink  Q  u  ality  (  entry  — >  neighbor  )  )  ; 

646 

found  |=  (pathEtx  <  neighEtx); 

647 

} 

648 

delete  msg  ; 

649 

return  found  ; 

650 

} 

651 

652 

/************************************************************/ 

653 

/*  Routing  Table  Functions  */ 

654 

655 

/*  The  routing  table  keeps  info  about  neighbor  ’s  route-info  , 

656 

*  and  is  used  when  choosing  a  parent. 

657 

*  The  table  is  simple  : 

658 

*  —  not  fragmented  (all  entries  in  0..routingTableActive) 

659 

*  —  not  ordered 

660 

*  —  no  replacement  :  eviction  follows  the  LinkE  stimat  or  table 

661 

*/ 

662 

663 

void  CtpRoutingEngine  :  :  routingTablelnit  ()  { 

664 

routingTable  Active  =  0; 

665 

} 

666 

667 

/*  Returns  the  index  of  parent  in  the  table  or 

668 

*  r  o  utin  g  T  abl  e  A  ctiv  e  if  not  found  */ 

669 

uint8_t  CtpRoutingEngine  ::  routingTableFind  (  am.addr.t  neighbor)  { 

670 

uint8_t  i  ; 

671 

if  (neighbor  ==  INVALID_ADDR ) 

672 

return  routingTable  Active  ; 

673 

for  (i  =  0;  i  <  routingTable  Active  ;  i  ++)  { 

674 

if  (routingTable  [  i  ]  .  neighbor  =  neighbor  ) 

675 

break ; 

676 

} 
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677 

678 

679 

680 
681 

682 

683 

684 

685 

686 

687 

688 

689 

690 

691 

692 

693 

694 

695 

696 

697 

698 

699 

700 

701 

702 

703 

704 

705 

706 

707 


} 


return  i  ; 


error.t  CtpRoutingEngine  :  :  routingTableUpdateEntry  (  am.addr  _t  from  ,  am.addr.t  parent  ,  uintl6_t  etx  , 
am.addr.t  nonepstld)  { 

uint  8  _t  idx  ; 
uintl6_t  linkEtx  ; 

linkEtx  =  evaluateEtx  (  le  —  >command_LinkEstimator  _getLinkQuality  (  from  )  )  ; 

idx  =  routingTableFind  (  from  )  ; 
if  (idx  ==  routingT ableSize  )  { 

//not  found  and  table  is  full 
/ /  if  (  passLinkEtxThreshold  (  linkEtx  )  ) 

//TODO :  add  replacement  here  ,  replace  the  worst 

//} 

trace  (  )  «”  routingTableUpdateEntry  _F  AIL  ,_table_full”  ; 
return  FAIL; 

} 

else  if  (idx  ==  routingTableActive)  { 

//not  found  and  there  is  space 

if  (  passLinkEtxThreshold  (  linkEtx  )  )  { 

routingTable  [idx].  neighbor  =  from; 
routingT  able  [  idx  ].  nonepstld  =  nonepstld; 
routingTable  [idx  ]  .  info  .  parent  =  parent  ; 
routingTable  [idx].  info. etx  =  etx; 
routingTable  [idx].  info. haveHeard  =  1; 
routingTable  [idx  ]  .  info  .  congested  =  false  ; 
routingT  ableActive-| — 

trace  (  )«”  routingTableUpdateEntry  „OK,  ^new^entry”  ; 
if  (nonepstld  !=  none  my  _pstld  ) 

trace  (  )«”^Lmy  _pst  Id  :  „”<<(int  )  none  my  _pst  Id  «”  ^neighbor^pstld  :  „”«nonepstI  d 
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}  else  { 

trace  (  )«”  routingTableUpdateEntry  _  F  ail  ,  _link_quality_(”<<(int  )  linkEtx  «”  )  _  below  _ 
threshold”  ; 

} 

}  else  { 

//found,  just  update 

routingTable  [idx].  neighbor  =  from; 
routingTable  [idx  ]  .  info  .  parent  =  parent  ; 
routingTable  [idx].  info,  etx  =  etx; 
routingTable  [idx  ]  .  info  .  haveHeard  =  1  ; 

trace  (  )«”  routingTableUpdateEntry  „-^OK,  „updated^entry”  ; 

} 

return  SUCCESS; 

} 

/*  if  this  gets  expensive  ,  introduce  indirection  through  an  array  of  pointers  */ 
error.t  CtpRoutingEngine  :  :  routingTableEvict  (  am.addr.t  neighbor)  { 
uint8_t  idx  ,  i  ; 

idx  =  routingTableFind  (  neighbor  )  ; 
if  (idx  ==  routingTableActive  ) 
return  FAIL; 
routingTableActive - ; 

for  (i  =  idx;  i  <  routingTableActive;  iH — |-)  { 
routingTable  [  i  ]  =  routingTable  [  i  + 1]  ; 

} 

return  SUCCESS; 

} 

/***********  end  routing  table  functions  ***************/ 

//  Collection  Debug  skipped  — >  not  useful  in  our  implementation 
/* 

*  Ctp  Routing  P  acket  Interface - 

*/ 

bool  CtpRoutingEngine  ::  command.CtpRoutingPacket.getOption  (  cPacket  *  msg  ,  ctp.options.t  opt)  { 
return  ( (  getHeader  (msg)—  >getOptions  ( )  &  opt)  =  opt)  ?  true  :  false; 

} 
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744 

745  void  CtpRoutingEngine  :  :  command.CtpRoutingPacket.setOption  (  cPacket  *  msg  ,  ctp.options.t  opt)  { 

746  get  Header  (  msg  )—>s  et  O  pt  ions  (  get  Header  (  msg  )—>get  O  pt  ions  (  )  |  opt)  ; 

747  } 

748 

749  void  CtpRoutingEngine  ::  command.CtpRoutingPacket.clearOption  ( cPacket  *  msg,  ctp.options.t  opt )  { 

750  get  Header  (  msg  )— >set  O  pt  ions  (  get  Header  (  msg  )— >get  O  pt  ions  (  )  &  ~opt)  ; 

751  } 

752 

753  void  CtpRoutingEngine  :  :  command.CtpRoutingPacket.clearOptions  (cPacket*  msg)  { 

754  get  Header  (  msg  )— >set  O  pt  ions  (  0  )  ; 

755  } 

756 

757  am.addr.t  CtpRoutingEngine  :  :  command.CtpRoutingPacket.getParent  (  cPacket*  msg)  { 

758  return  getHeader  (  msg)—  >getParent  ()  ; 

759  } 

760  void  CtpRoutingEngine  :  :  command.CtpRoutingPacket.setParent  (  cPacket*  msg  ,  am.addr.t  addr )  { 

761  getHeader  (  msg)—  >set  Parent  (addr)  ; 

762  } 

763 

764  uintl6_t  CtpRoutingEngine  ::  command.CtpRoutingPacket.getEtx  (  cPacket  *  msg)  { 

765  return  getHeader  (  msg)—  >getEtx  (  )  ; 

766  } 

767 

768  void  CtpRoutingEngine  ::  command.CtpRoutingPacket.setEtx  (  cPacket  *  msg,  uint8_t  etx)  { 

769  get  Header  (  msg  )—>set  Etx  (  etx  )  ; 

770  } 

771  //  - 

772 

773  /* 

774  *  Ctplnfo  Interface  (Part  2) - 

775  */ 

776  uint8_t  CtpRoutingEngine  :  :  command.CtpInfo.numNeighbors  ()  { 

777  return  r  o  u  t  i  ngT  able  A  ct  i  ve  ; 

778  } 

779 

780  uintl6_t  CtpRoutingEngine  ::  command.CtpInfo.getNeighborLinkQuality  (  uint8_t  n)  { 

781  return  (n  <  routingTable  Active  )  ?  le  —  >command_LinkEstimator_getLinkQuality  (  routingTable  [  n  ].  neighbor 

)  :  0  xffff  ; 

782  } 

783 

784  uintl6_t  CtpRoutingEngine  ::  command.CtpInfo.getNeighborRouteQuality  (  uint8  _t  n)  { 

785  return  (n  <  routingTable  Active  )  ?  le  — >command_LinkEstimator_getLinkQuality  (  routingTable  [  n  ].  neighbor 

)  +  r  out  i  ngTable  [  n  ]  .  i  n  f  o  .  etx  :  0  x  f  f  f  f  f  ; 

786  } 

787 

788  am.addr.t  CtpRoutingEngine  ::  command.CtpInfo.getNeighbor  Addr  (  u i n t  8  _t  n)  { 

789  return  (n  <  routingTable  Active  )  ?  routingTable  [  n  ].  neighbor  :AM_BROADCAST_ADDR  ; 

790  } 

791  //  - 

792 

793 

794  ////////////////////////////  Custom  functions  ///////////////////////////////////// 

795  /////////////////////////////////////////////////////////////////////////////////// 

796 

797  //  These  functions  trigger  an  event  in  the  module  where  they  should  signal  it  . 

798  void  CtpRoutingEngine  :  :  signal.Routing.routeFound  ()  { 

799  cfe  — >event_UnicastNameFreeRouting_routeFound  (  )  ; 

800  } 

801  void  CtpRoutingEngine  :  :  signal.Routing.noRoute  ()  { 

802  cf e —>e vent _Unicast N ameFreeRouting_r out eFound  (  )  ; 

803  } 

804 

805  /* 

806  *  AMPacket  Interface  (just  what  we  need) - 

807  */ 

808  am.addr.t  CtpRoutingEngine  ::  command.AMPacket.source  (  cMessage  *  msg)  { 

809  RoutingPacket  *  rPkt  =  check.and  .cast  <Rout ingPacket  *  > (msg )  ; 

810  return  (uintl6_t)  rPkt  — >ge  t  Ro  u  t  i  ngl  n  t  e  r  ac  t  i  o  n  C  o  n  t  r  o  1  (  )  .  last  Hop  ; 

811 


} 


812 

813  am.addr.t  CtpRoutingEngine  :  :  command.AMPacket.address  (  )  { 

814  return  self  ; 

815  } 

816  // - 

817 

818  //  these  functions  simulate  the  post  command 

819  void  CtpRoutingEngine  ::  post  _updateRouteTask  (  ) 

820  set  Timer  (POST  JJPD  ATEROUTETASK,0)  ;  // 

more  similar  to  the  post  command 

821  } 

822 

823  void  CtpRoutingEngine  :  :  post.sendBeaconTask  ()  { 

824  setTimer  ( POSTJ3ENDBEACONTASK ,  0  )  ; 

825  } 

826 

827  /////////////////////////////////////////////////////////////////////////////////// 

828  /////////////////////////////////////////////////////////////////////////////////// 


of  TinyOs 
{ 

cannot  call  the  up  dateR  outeT  ask  direct 
in  TinyOs  . 


CTP  Routing  Engine  Header: 

1  #i  f n  d  e  f  _CTPROUTIN GEN GINE_H_ 

2  #define  _CTPROUTIN GEN GINE_H_ 

3 

4  ^include  ”  Ctp  .  h” 

5 

6  using  namespace  std  ; 

7 

8 

9  ///////////////////////////  TreeR outing  .  h  //////////////////////////// 

10  ////////////////////////////////////////////////////////////////////// 

11 

1 2  enum  { 

13 

14 

15 

16 

17 

18 

19  }; 

20 
21 

22  typedef  struct  { 

23  am.addr.t  parent  ; 

24  uintl6.t  etx  ; 

25  bool  haveHeard  ; 

26  bool  congested  ; 

27  }  route.info.t  ; 

28 

29  typedef  struct  { 

30  am.addr.t  neighbor  : 

31  am.addr.t  nonepstld 

32  route.info.t  info; 

33  }  routing.table.entry; 

34 

35  inline 

36 

37 

38 

39 

40  } 

41 

42  ////////////////////////////////////////////////////////////////////// 

43  ////////////////////////////////////////////////////////////////////// 

44 

45 

46  //////////////////////////  Custom  values  ///////////////////////////// 

47  ////////////////////////////////////////////////////////////////////// 


void  routeInfoInit(route_info.t  *ri)  { 
ri— >parent  =  INVALID_ADDR ; 
r  i  — >  etx  =  0  ; 
r  i  — >haveHeard  =  0; 
r  i  — >  congested  =  false  ; 


AM_TREE_ROUTIN  G-CONTROL  =  OxCE, 

BEACON  JNTERVAL  =  8192, 

INVALID_ADDR  =  Oxffff  , 

ETX_THRESHOLD  =50,  //link  quality  =20%  ->  ETX=5  ->  Metric  =50 

PARENT_SWITCH_THRESHOLD  =  15, 

MAXJVIETRIC  =  OxFFFF , 
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63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 


enum  { 

BEACON.TIMER  =  1  , 
ROUTE.TIMER  =  2  , 
POST.UPDATEROUTETASK  =  3  , 
POSTJ3ENDBEACONTASK  =  4  , 

}; 


////////////////////////////////////////////////////////////////////// 

////////////////////////////////////////////////////////////////////// 


class  CtpRoutingEngine  ; 
class  LinkEstimator  ; 

class  CtpRoutingEngine:  public  CastaliaModule  ,  public  TimerService  { 
protected : 

///////////////////////  CtpRoutingEngineP  . nc  ////////////////////////// 

/////////////////////////////////////////////////////////////////////// 

bool  ECNOff  ; 
bool  radioOn  ; 
bool  running  ; 
bool  sending  ; 
bool  justEvicted  ; 


route_info_t  routelnfo 
bool  s  t  a  t  e  _i  s  _r  o  o  t  ; 
am_addr_t  my_ll_addr; 


am.addr.t  nonemy.pstld  ;  //  my  pstID  is  that  of  my  parent  ’ 

cPacket  beaconMsgBuffer  ; 

CtpBeacon*  beaconMsg  ;  //  we  don  ’ t  need  a  pointer  to  the  header  ,  we  use  methods  of  cPacket  instead 
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/*  routing  table  -  routing  info  about  neighbors  */ 

routing.table.entry*  routingTable  ; 
uint8_t  routingTable  Active  ; 

/*  statistics  */ 
uint32_t  parentChanges  ; 

/*  end  statistics  */ 
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uint32_t  routeUpdateTimerCount  ; 


uint32_t  c  u  r  r  e  n  1 1  n  t  e  r  v  a  1  ; 

uint32  _t  t  ; 

bool  tHasPassed  ; 

/////////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////////// 

///////////////////////  Custom  Variables  ////////////////////////////// 

/////////////////////////////////////////////////////////////////////// 

//  Pointers  to  other  modules. 

CtpForwardingEngine  *cfe  ; 

LinkEstimator  *le  ; 

ResourceManager  *  resMgrModule  ; 


//  Beacon  Frame  size  . 
int  ctpReHeaderSize  ; 


//  Node  Id  . 
int  self; 


//  Sets  a  node  as  root  from  omnetpp  .  ini 
bool  isRoot  ; 


//  Sets  a  node  as  a  sinkhole  from  omnetpp  .  ini 
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bool  isSink  ; 

//  Arguments  of  generic  module  Ctp Routing EngineP 
uint32_t  minlnterval  ; 
uint32_t  maxlnterval  ; 
uint8_t  routingTableSize  ; 

/////////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////////// 

/////////////////  Castalia  Functions  ///////////////////////////// 

////////////////////////////////////////////////////////////////// 

virtual  void  initialize  ()  ; 

virtual  void  handleMessage  ( cMessage  *  msg)  ; 
void  t  i  me  r  F  i  r  ed  C  al  1  b  ac  k  (  in  t  timer)  ; 
virtual  ~  CtpRoutingEngine  (  )  ; 

/////////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////////// 

///////////////////  CtpRoutingEngine  functions  //////////////////// 

/////////////////////////////////////////////////////////////////// 

void  choose  AdvertiseTime  (  )  ; 
void  resetlnterval  ()  ; 
void  decaylnterval  ()  ; 
void  r  emaininglnter  val  (  )  ; 

bool  passLinkEt xT hr eshold  (  u  i  n  1 1  6  _t  etx  )  ; 

uintl6_t  e  val  uat  eE  t  x  (  u  i  n  1 1  6  _t  quality)  ; 

void  updateRouteTask  ()  ; 

void  sendBeaconTask  ()  ; 

void  e  ven t  _Ro u t  e T i me r  _f  i r  e d  (  )  ; 

void  event  .BeaconTimer.fired  (  )  ; 

CtpBeacon*  getHeader  ( cPacket*  msg)  ; 

void  r  out  ingTablelnit  (  )  ; 

uint8_t  routingTableFind  (  am.addr.t  )  ; 

error.t  routingTablellpdateEntry  (  am.addr.t  ,  am.addr.t  ,  uintl6_t  ,  am.addr.t)  ; 
error.t  routingTableEvict  (  am.addr.t  )  ; 

//  Ctp R  outing P acket  Interface - 

bool  command.CtpRoutingPacket.getOption  (  cPacket*  msg ,  ctp.options.t  opt); 
void  command.CtpRoutingPacket.setOption  ( cPacket*  msg ,  ctp.options.t  opt); 
void  command.CtpRoutingPacket.clearOption  (cPacket*  msg ,  ctp.options.t  opt); 
void  command  _Ct  pRoutingP  acket  .clearO  pt  ions  (  cP  acket  *  msg); 
am.addr.t  command.CtpRoutingPacket.getParent  (  cPacket*  msg); 
void  command.CtpRoutingPacket.setParent  (  cPacket  *  msg,  am.addr.t  addr  )  ; 
uintl6_t  command.CtpRoutingPacket.getEtx  (  cPacket  *  msg); 
void  command.CtpRoutingPacket.setEtx  (  cPacket*  msg  ,  uint8_t  etx); 

// - 

/////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////// 

///////////////////  Custom  functions  ////////////////////////////// 

/////////////////////////////////////////////////////////////////// 

//  generates  an  event  in  the  module  where  they  should  signal  it. 
void  signal.Routing.routeFound  ()  ; 

void  signal.Routing.noRoute  ()  ; 

//  AMPacket  Interface  ( just  what  we  need) - 

am.addr.t  command.AMPacket.source  ( cMessage*  msg); 


am.addr.t  command.AMPacket.address  (  )  ; 

// - 
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//  functions  that  simulate  the  post  command  of  TinyOs 
void  post.sendBeaconTask  (  )  ; 

void  post.updateRouteTask  ()  ; 

/////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////// 

public  : 

///////////////////  CtpRoutingEngine  functions  //////////////////// 

/////////////////////////////////////////////////////////////////// 

error.t  command.StdControl.start  ()  ; 
error.t  command.StdControl.stop  ()  ; 

void  event.RadioControl.startDone  (error.t  error)  ; 
void  event.RadioControl.stopDone  (error.t  error)  ; 

void  event  _B  eaconSend.sendDone  (  cMessage  *  msg  ,  error.t  error)  ; 

void  event.BeaconReceive.receive  (cPacket*  msg); 

void  event_LinkEstimator.evicted(  am.addr.t  neighbor)  ; 

//  UnicastN  ameFreeRouting  Interface - 

bool  command.Routing.hasRoute  (  )  ; 

am.addr.t  command.Routing.nextHop  (  )  ; 

// - 

//  Ctplnfo  Interface  (Part  1) - 

error.t  command.CtpInfo.getParent  (  am.addr.t  *)  ; 

uint8_t  command.Ct  pInfo_get  Etx  (  u  i  n  1 1  6  _t  *  etx)  ; 
void  command.CtpInfo.recomputeRoutes  (  )  ; 

void  command.CtpInfo.triggerRouteUpdate  ()  ; 

void  command.CtpInfo.triggerlmmediateRouteUpdate  ()  ; 

void  command.CtpInfo.setNeighborCongested  (  uint  1  6  _t  n  ,  bool  congested) 
bool  command  _Ct  pInfo_is  Neighbor  C  ongested  (  u  i  n  1 1  6  _t  addr)  ; 

// - 

//  Ro  otControl  Interface - 

bool  command.RootControl.isRoot  ()  ; 
error.t  command.RootControl.setRoot  ()  ; 

error.t  command.RootControl.unsetRoot  ()  ; 

// - 

bool  event.CompareBit.shouldlnsert  (cPacket  *msg ,  bool  white_bit)  ; 

//  Ctplnfo  Interface  (Part  2) - 

uint8_t  command.CtpInfo.numNeighbors  ( )  ; 

uintl6_t  command  _Ct  pi  nfo  _get  Neighbor  LinkQuality  (  u  i  n  t  8  _t  )  ; 

uintl6_t  command.CtpInfo.getNeighborRouteQuality  (  uint  8  _t  )  ; 

am.addr.t  command.CtpInfo.getNeighbor  Addr  (  u  i  nt  8  _t  )  ; 

// - 


}; 

ffe  n  d  i  f 


/////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////// 


